| Summary: | objdump -l reports wrong line numbers | ||
|---|---|---|---|
| Product: | binutils | Reporter: | Andi Kleen <andi-bz> |
| Component: | binutils | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED NOTABUG | ||
| Severity: | normal | CC: | nickc |
| Priority: | P2 | ||
| Version: | 2.22 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
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...
. |
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.