Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Adding Blank Line In Source Causes Change In Executable
47 views
Skip to first unread message
Morris, John M CIV NSWCDD, Q34
Mar 6, 2012, 8:32:14 AM3/6/12
to
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
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
glen herrmannsfeldt
Mar 6, 2012, 2:51:17 PM3/6/12
to
Morris, John M CIV NSWCDD, Q34 <john.m...@navy.mil> wrote:
(snip)
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
(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.
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
Robert A Duff
Mar 6, 2012, 4:25:28 PM3/6/12
to
"Morris, John M CIV NSWCDD, Q34" <john.m...@navy.mil> writes:
> ...in my case I am using AdaCore's GPS
(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
> ...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.)
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
HOKIENERD
Mar 12, 2012, 10:36:39 AM3/12/12
to
On Mar 6, 5:25 pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
SNIP
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
>
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,
> 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
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
Robert A Duff
Mar 13, 2012, 9:34:30 AM3/13/12
to
You're welcome.
>... I hope to get
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
>... 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?
> check, but lose the line number!
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
glen herrmannsfeldt
Mar 14, 2012, 1:26:05 AM3/14/12
to
Robert A Duff <bob...@shell01.theworld.com> wrote:
> HOKIENERD <hoki...@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
> HOKIENERD <hoki...@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?
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
HOKIENERD
Mar 26, 2012, 10:33:29 AM3/26/12
to
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
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
Robert A Duff
Mar 26, 2012, 1:36:43 PM3/26/12
to
HOKIENERD <hoki...@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
> 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!
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.
0 new messages