This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Comments in assember output


On Friday 2006-12-01 Fabian Cenedese wrote:

>                                           ... But when I tried it
> it didn't mix the lines, I just got (almost) all lines from the cpp
> source file and after that the assembler code.

I have seen this effect quite regularly.  I do not know this for a
fact but have always assumed that the incorporation of source code
into the assembly listing was a classic stream merge based on line
numbers.  This works okay as long as the generated code closely
parallels the source.  It also depends on what bits of intermediate
representation are allowed to claim source line correspondence.

The reason that I suggest this explanation is that the gcc behavior
seems very reminiscent of what I used to see for a while from the Apollo
compilers.  A classic example was an assignment within a loop with an
invariant RHS.  If the RHS required any expression evaluation and if
the instructions carrying out that evaluation was moved out of the
loop then all loop source lines up to and including that assignment
would be emitted ahead of the loop in the vicinity of the RHS evaluation.

I am writing from rather foggy memories but I believe that the fix was
to mark instructions with both a putative line number and a boolean
flag indicating whether or not the instruction corresponded to a
significant source side-effect.  The listing format included a source
line number as an end-of-line comment.  Thus a motioned expression
could still be traced back to a source line.  Source lines were merged
into the assembly file using the classic scheme alluded to above with
the following refinement.  When an assembly instruction included a source
line correlation higher than the most recently merged source line that
line number correlation was ignored unless either a) that instruction was
flagged as a significant side-effect or b) there was an uninterrupted run
of instructions with that same line number correlation ultimately leading
to an instruction that was flagged as a significant side-effect.

As I recall the motivation for making these changes was not more readable
assembly listing but a need for saner information in the debugger's pc
correlation table.

/john


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]