bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/21977] New: C asm statement results in C source in assembler li


From: pderocco at ix dot netcom.com
Subject: [Bug gas/21977] New: C asm statement results in C source in assembler listing, even without -ah option
Date: Sat, 19 Aug 2017 08:01:28 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=21977

            Bug ID: 21977
           Summary: C asm statement results in C source in assembler
                    listing, even without -ah option
           Product: binutils
           Version: 2.27
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gas
          Assignee: unassigned at sourceware dot org
          Reporter: pderocco at ix dot netcom.com
  Target Milestone: ---

Created attachment 10353
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10353&action=edit
Files to reproduce bug

I've attached several files in a Zip file:

test-inline.c -- a five-line C program that uses an asm statement.

test-inline.sh -- the command line that was generated by Eclipse to compile it.
Note it has no -g option, but it explicitly passes -aldg to the assembler, to
produce a low-level listing, strip debug output, and show the assembler
options.

test-inline.S -- the assembly language spat out by the compiler. It only
contains the expansion of the asm, but wraps it in #APP and #NO_APP, and a
directive indicating what C source line generated it.

test-inline.lst -- the assembler listing.

foo.txt -- a snippet from a much larger program's assembler listing (see
below).

Even though -ah isn't passed to the assembler, when it sees #APP, it fetches
the C source and inserts it into the listing. Yet it doesn't just show the asm
statement, but it shows everything before it back to the beginning of the file,
which on a real program can be a lot of junk. Second, while it follows the C
source with the expanded asm output (the "addl %edx, %eax"), it puts the hex
opcodes on the same line as the C asm statement, not the expansion. It takes
some work to make it do that, so whoever wrote that part of the assembler must
have thought it was a Good Idea, not an accident.

If you look at foo.txt, you can see that when it does this in more complicated
cases, which I can't really narrow down to a short test program, it can get
confused and put the opcodes before the wrong C source lines.

But the more immediate, and probably easier to fix, problem is that with no -ah
option, the assembler has no business doing any of this. It looks like the code
that handles the #APP comment just assumes that C source should be included,
without seeing if -ah was specified. In a big program with a lot of asm
statements inside inline functions inside include files, the result is an
almost unreadable assembler listing. All I want is a clean listing with no C
source. That should be pretty simple.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]