Bug 16433 - objdump -l reports wrong line numbers
Summary: objdump -l reports wrong line numbers
Status: WAITING
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.22
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-11 06:16 UTC by Andi Kleen
Modified: 2014-01-14 13:03 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andi Kleen 2014-01-11 06:16:35 UTC
objdump --version
GNU objdump (GNU Binutils; openSUSE 12.2) 2.22

Simple file:

     1	
     2	volatile a = 10000, b = 100000, c;
     3	
     4	__attribute__((noinline)) f2()
     5	{
     6		c = a / b;
     7	}


Dumping the compiled simple file with objdump -Sl I get

00000000004004ec <f2>:
f2():
/home/ak/hle/tsrc/tcall.c:5

volatile a = 10000, b = 100000, c;

__attribute__((noinline)) f2()
{
  4004ec:       55                      push   %rbp
  4004ed:       48 89 e5                mov    %rsp,%rbp
tcall.c:6
        c = a / b;
  4004f0:       8b 05 22 0b 20 00       mov    0x200b22(%rip),%eax        # 601018 <a>
  4004f6:       8b 15 20 0b 20 00       mov    0x200b20(%rip),%edx        #   60101c <b>
  4004fc:       89 55 fc                mov    %edx,-0x4(%rbp)


The problem is the tcall.c:5. The first empty line it shows is actually line 1, not 5. Line 5 is the first executable statement. But when showing context it should adjust the line nr to the context offset.
Comment 1 Nick Clifton 2014-01-14 13:03:13 UTC
Hi Andi,

> But when showing context it should adjust the line nr to the context offset.

Why should it do this ?  Is it documented that it will ?

The current behaviour is to display the context leading up to the specified line, rather than the context from the specified line to the line is responsible for generating the disassembly that follows.  This makes sense to me.  The line number displayed is the number of the line that caused the assembler to be generated.

Cheers
  Nick

PS.  In future bug reports it would be helpful if you could provide additional information such as the target environment and the command line used to compile the test case.  It also helps if you test with the latest binutils. 2.22 is now two releases old...