https://sourceware.org/bugzilla/show_bug.cgi?id=20337
Bug ID: 20337
Summary: Objdump incorrectly disassembles zero-length functions
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: aivchenk at gmail dot com
Target Milestone: ---
When compiling the following code:
int f() {}
int g() {}
int h() {}
int main() {
return 0;
}
with Clang/LLVM ($clang a.cpp -O2; I used 3.7) functions f, g, h, main have the
same starting address:
0000000000400500 g F .text 0000000000000000 f()
0000000000400500 g F .text 0000000000000000 g()
0000000000400500 g F .text 0000000000000000 h()
0000000000400500 g F .text 0000000000000003 main
While it is controversial
(http://stackoverflow.com/questions/26533740/do-distinct-functions-have-distinct-addresses)
whether clang produces a sane result here, the objdump behavior for this file
is clearly confusing and incorrect:
Here is the output of 'objdump -Cd a.out':
...
0000000000400500 <f()>:
400500: 31 c0 xor %eax,%eax
400502: c3 retq
400503: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
40050a: 00 00 00
40050d: 0f 1f 00 nopl (%rax)
...
The output from objdump should label this function as 'main' since the size of
the function 'f' is 0 as stated in the symbol table, and the size of 'main' is
3 (which is apparently used by objdump to determine the function boundaries).
There are no functions 'g()', 'h()' and 'main()' in the objdump output, but
they probably should be present since mentioned in the symbol table. Or
probably it is okay that they are missing since there is no assembly code for
them (once 'f()' in the dump is renamed to 'main()', and 'f()' becomes missing
in the dump).
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
