Bug 21977 - C asm statement results in C source in assembler listing, even without -ah option
Summary: C asm statement results in C source in assembler listing, even without -ah op...
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: gas (show other bugs)
Version: 2.27
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-19 08:01 UTC by Paul D. DeRocco
Modified: 2017-10-11 15:51 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Files to reproduce bug (2.00 KB, application/x-zip-compressed)
2017-08-19 08:01 UTC, Paul D. DeRocco
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul D. DeRocco 2017-08-19 08:01:28 UTC
Created attachment 10353 [details]
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.
Comment 1 cvs-commit@gcc.gnu.org 2017-10-11 15:49:36 UTC
The master branch has been updated by Nick Clifton <nickc@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=39865a7f420ab4ca4dec6ed27339618a5d5dc366

commit 39865a7f420ab4ca4dec6ed27339618a5d5dc366
Author: Nick Clifton <nickc@redhat.com>
Date:   Wed Oct 11 16:48:16 2017 +0100

    Disable the inclusion of logical input files in the assembler listing output unless high level source listing has been enabled.
    
    	PR 21977
    	* listing.c (listing_newline): Use the name of the current
    	physical input file, rather than the current logical input file,
    	unless including high level source in the listing.
    	* input-scrub.c (as_where_physical): New function.  Returns the
    	name of the current physical input file.
    	* as.h: Add prototype for as_where_physical.
Comment 2 Nick Clifton 2017-10-11 15:51:42 UTC
Hi Paul,

  Right - I have checked in a small patch to prevent the inclusion of the source file in the listing output unless -ah is used.  I have not changed the behaviour when -ah is used however, even though it can produce extravagantly long listings, as you pointed out.  I am worried that there are users out there who might rely upon this behaviour, so I did not want to change it.

Cheers
  Nick