Created attachment 50426 [details] Files with the source code, executables, and debuginfo demostrating DW_AT_entry_pc issue The generation of DW_AT_entry_pc values appears to be off. Attached DW_AT_entry_pc_example.tgz has files made on Fedora Rawide with the following commands demonstrating the issue. $ rpm -q gcc libdwarf-tools elfutils gcc-11.0.0-0.19.fc35.x86_64 libdwarf-tools-20210305-1.fc35.x86_64 elfutils-0.183-2.fc35.x86_64 $ gcc -O3 -g test2.c -o test2_gcc --save-temp $ dwarfdump test2_gcc > test2_gcc.dump $ eu-readelf --debug-dump=decodedline test2_gcc > test2_gcc.lines $ eu-readelf --debug-dump=ranges test2_gcc > test2_gcc.ranges $ objdump -d test2_gcc > test2_gcc.dis For the second inlined call to atoi (from the test2_gcc.dump) the DW_AT_entry_pc looks to be off below. Would expcet the entry to be 0x401069 at the beginning of argument setup rather than at the call to strtol 0x401077: < 2><0x00000171> DW_TAG_inlined_subroutine DW_AT_abstract_origin <0x000002d1> DW_AT_entry_pc 0x00401077 DW_AT_GNU_entry_view 2 DW_AT_ranges 0x00000022 Offset of rnglists entries: 0x00000022 [ 0] base address 0x00401069 0x00000000 [ 1] start,end 0x00401069 0x00401074 [ 2] start,end 0x00401077 0x0040107c [ 3] start,end 0x00401084 0x00401087 [ 4] end of list DW_AT_call_file 0x00000001 DW_AT_call_line 0x00000011 DW_AT_call_column 0x0000000b DW_AT_sibling <0x000001af> 401069: 48 8b 7b 10 mov 0x10(%rbx),%rdi 40106d: ba 0a 00 00 00 mov $0xa,%edx 401072: 31 f6 xor %esi,%esi 401074: 48 89 c5 mov %rax,%rbp 401077: e8 c4 ff ff ff call 401040 <strtol@plt> 40107c: 8d 75 01 lea 0x1(%rbp),%esi 40107f: bf 10 20 40 00 mov $0x402010,%edi 401084: 48 89 c3 mov %rax,%rbx 401087: Similiarly, things seem to be off for the inlined function f. For the first inlined instance of f (from the test2_gcc.dump) would expect the DW_AT_entry_pc to point to 0x40107c the first instruction assocated with the function and where the increment happens rather than 0x401087 Looking at the line information 0x401087 is associated with the beginning of the function, but at this point all the code associated with the function has executed: < 2><0x000001af> DW_TAG_inlined_subroutine DW_AT_abstract_origin <0x000002a1> DW_AT_entry_pc 0x00401087 DW_AT_GNU_entry_view 2 DW_AT_ranges 0x00000035 Offset of rnglists entries: 0x00000035 [ 0] base address 0x0040107c 0x00000000 [ 1] start,end 0x0040107c 0x0040107f [ 2] start,end 0x00401087 0x00401087 [ 3] end of list DW_AT_call_file 0x00000001 DW_AT_call_line 0x00000012 DW_AT_call_column 0x00000003 DW_AT_sibling <0x000001f8> 40107c: 8d 75 01 lea 0x1(%rbp),%esi 40107f: bf 10 20 40 00 mov $0x402010,%edi 401084: 48 89 c3 mov %rax,%rbx 401087: 31 c0 xor %eax,%eax The first inlined function g pretty much the same instruction as the the inlined f calling it. It also has the same DW_AT_entry_pc that is after the instructions for the function have executed. < 3><0x000001d4> DW_TAG_inlined_subroutine DW_AT_abstract_origin <0x000002b9> DW_AT_entry_pc 0x00401087 DW_AT_GNU_entry_view 4 DW_AT_ranges 0x00000035 Offset of rnglists entries: 0x00000035 [ 0] base address 0x0040107c 0x00000000 [ 1] start,end 0x0040107c 0x0040107f [ 2] start,end 0x00401087 0x00401087 [ 3] end of list DW_AT_call_file 0x00000001 DW_AT_call_line 0x0000000b DW_AT_call_column 0x0000000a
Jan Kratochvil at Red Hat mentioned that the DW_AT_entry_pc values looked reasonable when -gno-as-locview-support was added to the command line. I checked and they do look more reasonable. Does this mean an issue with gas from binutils-2.36.1-7.fc35.x86_64 ?
Created attachment 50479 [details] assembly file compiled with -gno-as-locview-support Resulting assembly language file generated by: gcc -O3 -g -gno-as-locview-support -fverbose-asm -S -o test3_gcc_nolocview.s test3.c This can be compared to test3_gcc_locview.s that will be uploaded in a moment.
Created attachment 50480 [details] Default assembly code generated by compiler Default Assembly generated by compiler to compare to the -gno-as-locview-support version that has more reasonable DW_AT_entry_pc values
A quick diff between the two -fverbose-asm dumps confirms that the generated object code is identical with or without the -gno-as-locview-support, but the DW_AT_entry_pc differs.
Confirmed then.