Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #474 > unrolled thread

Adding Blank Line In Source Causes Change In Executable

Back to article view | Back to comp.compilers

Contents

  Adding Blank Line In Source Causes Change In Executable "Morris, John M CIV NSWCDD, Q34" <john.m.morris@navy.mil> - 2012-03-06 08:32 -0500
    Re: Adding Blank Line In Source Causes Change In Executable glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-03-06 19:51 +0000
    Re: Adding Blank Line In Source Causes Change In Executable Robert A Duff <bobduff@shell01.TheWorld.com> - 2012-03-06 16:25 -0500
      Re: Adding Blank Line In Source Causes Change In Executable HOKIENERD <hokienerd@gmail.com> - 2012-03-12 07:36 -0700
        Re: Adding Blank Line In Source Causes Change In Executable Robert A Duff <bobduff@shell01.TheWorld.com> - 2012-03-13 09:34 -0400
          Re: Adding Blank Line In Source Causes Change In Executable glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-03-14 05:26 +0000
          Re: Adding Blank Line In Source Causes Change In Executable HOKIENERD <hokienerd@gmail.com> - 2012-03-26 07:33 -0700
            Re: Adding Blank Line In Source Causes Change In Executable Robert A Duff <bobduff@shell01.TheWorld.com> - 2012-03-26 13:36 -0400

#474 — Adding Blank Line In Source Causes Change In Executable

I apologize if this is a stupid question, but I have not been able to find any information on this subject. I think this question might be applicable to most compilers, but in my case I am using AdaCore's GPS development environment (which uses gcc I believe) to compile Ada programs for a 68040 processor. I am not intentionally including debug information in my builds.

I've noticed that if I add one blank line to a source file (e.g., I hit <Enter> right before the last assignment statement in the Ada file) and recompile, I get a different output/binary/executable file. (In this example, only one byte in the executable is different, and it is 1 greater than the original value. If I hit <Enter> 3 times and recompile, the byte is 3 greater than the original value.)

I assumed that blank lines in the source would have no impact on the executable, but that appears to be incorrect. Any help would be greatly appreciated.

Regards,
John

[toc] | [next] | [standalone]

#476

Morris, John M CIV NSWCDD, Q34 <john.m.morris@navy.mil> wrote:

(snip)
> I am not intentionally including debug information in my builds.

Some compilers may generate debugging by default. Others may not
even have an option to turn it off. On many systems, a link-time
option is needed to put the compiler generated debugging data into
the executable, but maybe not all.

> I assumed that blank lines in the source would have no impact on
> the executable, but that appears to be incorrect.

A common debugging feature allows for the printing of statement
numbers in error messages, which means that they have to get into
the executable. The usual optional debugging information, for
example -g in GNU compilers, allows variable names to be included
for debugging. Variable names tend to take up a lot more room
than just statement numbers.

Including source statement numbers does not necessarily follow
the same debugging option, and may even not be optional.

-- glen

[toc] | [prev] | [next] | [standalone]

#477

"Morris, John M CIV NSWCDD, Q34" <john.m.morris@navy.mil> writes:

> ...in my case I am using AdaCore's GPS
> development environment (which uses gcc I believe) to compile Ada

GPS is the IDE.  The compiler is GNAT, and yes, it's part of gcc
(the GNU Compiler Collection).

> programs for a 68040 processor. I am not intentionally including debug
> information in my builds.

> I've noticed that if I add one blank line to a source file (e.g., I
> hit <Enter> right before the last assignment statement in the Ada
> file) and recompile, I get a different output/binary/executable
> file. (In this example, only one byte in the executable is different,
> and it is 1 greater than the original value. If I hit <Enter> 3 times
> and recompile, the byte is 3 greater than the original value.)

My guess is that there's an implicit 'raise' of an exception, perhaps
for some constraint check on the assignment, and this contains the
line number, so it can print a message if the check fails, something
like:

Constraint_Error raised some_file.adb line 1234.

or something like that.

If you change the line number, that message will need to change.

If you look at the generated assembly code, you'll probably
see a call something like:

    Rcheck_12(File => ..., Line => 1234);

The -gnatD output might also show you what's going on.

- Bob

[toc] | [prev] | [next] | [standalone]

#495

On Mar 6, 5:25 pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
   SNIP
>
> My guess is that there's an implicit 'raise' of an exception, perhaps
> for some constraint check on the assignment, and this contains the
> line number, so it can print a message if the check fails, something
> like:
>
> Constraint_Error raised some_file.adb line 1234.
>
> or something like that.
>
> If you change the line number, that message will need to change.
>
> If you look at the generated assembly code, you'll probably
> see a call something like:
>
>     Rcheck_12(File => ..., Line => 1234);
>
> The -gnatD output might also show you what's going on.
>
> - Bob


Hi Bob,

It absolutely is the line number. (Thanks for the tip.) I hope to get
to the assembly code before too long. I sure wish I could keep the
check, but lose the line number!

Thanks,
John

[toc] | [prev] | [next] | [standalone]

#498

HOKIENERD <hokienerd@gmail.com> writes:

> It absolutely is the line number. (Thanks for the tip.)

You're welcome.

>... I hope to get
> to the assembly code before too long. I sure wish I could keep the
> check, but lose the line number!

Why?

I understand why one wants identical source code to produce
identical object files, and identical executable files.
(I don't like object file formats that include things
like time-of-compilation!)
But if you add blank lines, the source is no longer identical.
Surely that line number is useful, if the check ever fails.

There's an option to gnatmake that causes it to not recompile
things if the changes were trivial (e.g. whitespace and comment
changes), but then the debugging information will be slightly off.

- Bob

[toc] | [prev] | [next] | [standalone]

#503

Robert A Duff <bobduff@shell01.theworld.com> wrote:
> HOKIENERD <hokienerd@gmail.com> writes:

>> It absolutely is the line number. (Thanks for the tip.)

> You're welcome.

>>... I hope to get to the assembly code before too long.
>> I sure wish I could keep the check, but lose the line number!

> Why?

All the OS/360 compilers I remember had an option to turn on or
off keeping the statement numbers. When memory was small, it might
have made a difference.

In the case of PL/I on the 360/91, though, when statement numbering
was on the compiler generated BR 0 instructions between each statement,
which flushes the 360/91 (and any other out-of-order processor) pipeline
such that the number would be right. That was the default on the
systems I used, too.

-- glen

[toc] | [prev] | [next] | [standalone]

#524

I finally got to the assembly code, and it is indeed rcheck_12 (and a
few similar checks).

We were hoping to add comments throughout the code, and 'prove' that
they had no effect by producing an identical executable, but it looks
like we won't be able to do that.

The line number is useful in our debug environment, but in our final
system there is nowhere for the information to be output, so it won't
do us any good in that configuration.

I sure can't find a way to turn it off on my system!

Thanks for all the help!

John

[toc] | [prev] | [next] | [standalone]

#525

HOKIENERD <hokienerd@gmail.com> writes:

> We were hoping to add comments throughout the code, and 'prove' that
> they had no effect by producing an identical executable, but it looks
> like we won't be able to do that.
>
> The line number is useful in our debug environment, but in our final
> system there is nowhere for the information to be output, so it won't
> do us any good in that configuration.
>
> I sure can't find a way to turn it off on my system!

If you buy the GNAT Pro product from AdaCore, they would probably be
willing to add such a feature.

Alternatively, you could modify the compiler and run-time system
yourself to remove these line numbers.

- Bob

P.S. Note that I work for AdaCore.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compilers

csiph-web