Bug 24856 - dwarf_diename() cannot get correct name
Summary: dwarf_diename() cannot get correct name
Status: RESOLVED INVALID
Alias: None
Product: elfutils
Classification: Unclassified
Component: libdw (show other bugs)
Version: unspecified
: P2 critical
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-27 13:40 UTC by Changbin Du
Modified: 2020-01-10 15:14 UTC (History)
3 users (show)

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


Attachments
object file (72.48 KB, application/x-object)
2019-07-27 13:40 UTC, Changbin Du
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Changbin Du 2019-07-27 13:40:20 UTC
Created attachment 11923 [details]
object file

The allfcts get all symbols as the same name.
elfutils/tests$ ./allfcts ../../linux/kernel/iomem.o 
kernel/iomem.c:162:x86_coreid_bits
kernel/iomem.c:139:x86_coreid_bits
kernel/iomem.c:134:x86_coreid_bits
kernel/iomem.c:129:x86_coreid_bits
kernel/iomem.c:122:x86_coreid_bits
kernel/iomem.c:71:x86_coreid_bits
kernel/iomem.c:30:x86_coreid_bits
kernel/iomem.c:16:x86_coreid_bits
./include/linux/mm.h:626:x86_coreid_bits
./include/linux/device.h:1105:x86_coreid_bits
./include/linux/mmzone.h:1297:x86_coreid_bits
./include/linux/mmzone.h:1262:x86_coreid_bits
./include/linux/mmzone.h:1212:x86_coreid_bits
./include/linux/mmzone.h:1151:x86_coreid_bits
./include/linux/page-flags.h:372:x86_coreid_bits
./include/linux/err.h:24:x86_coreid_bits

But dwfl API works:
elfutils/tests$ ./funcretval -e ../../linux/kernel/iomem.o 
() devm_memunmap: returns no value
() devm_memremap: return value location: {0x50, 0}
() devm_memremap_match: return value location: {0x50, 0}
() devm_memremap_release: returns no value
() memunmap: returns no value
() memremap: return value location: {0x50, 0}
() try_ram_remap: return value location: {0x50, 0}
() arch_memremap_wb: return value location: {0x50, 0}
() is_vmalloc_addr: return value location: {0x50, 0}
() dev_to_node: return value location: {0x50, 0}
() pfn_valid: return value location: {0x50, 0}
() valid_section: return value location: {0x50, 0}
() __nr_to_section: return value location: {0x50, 0}
() pfn_to_section_nr: return value location: {0x50, 0}
() PageHighMem: return value location: {0x50, 0}
() ERR_PTR: return value location: {0x50, 0}
Comment 1 Changbin Du 2019-07-27 13:46:11 UTC
BTW, the latest master branch has build failure.

  CCLD     libebl_sparc.so
  CCLD     libebl_ppc.so
  CCLD     libebl_ppc64.so
  CCLD     libebl_s390.so
  CCLD     libebl_tilegx.so
  CCLD     libebl_m68k.so
  CCLD     libebl_bpf.so
  AR       libebl_riscv_pic.a
  CCLD     libebl_riscv.so
/usr/bin/ld: libebl_riscv_pic.a(riscv_init.os): relocation R_X86_64_PC32 against undefined hidden symbol `riscv64_core_note' can not be used when making a shared object
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:1299: libebl_riscv.so] Error 1
make[1]: *** [Makefile:486: all-recursive] Error 1
make: *** [Makefile:402: all] Error 2
Comment 2 Mark Wielaard 2019-07-27 14:28:00 UTC
(In reply to Changbin Du from comment #0)
> The allfcts get all symbols as the same name.
> elfutils/tests$ ./allfcts ../../linux/kernel/iomem.o 
> [...]
> But dwfl API works:
> elfutils/tests$ ./funcretval -e ../../linux/kernel/iomem.o 

This is because the iomem.o ET_REL file has relocations between the debug sections. When using libdwfl those relocations are resolved automatically. If the relocations aren't resolved before using the plain libdw interfaces it looks like all references into the .debug_str section look like pointing to the "zero string" (which happens to be  [   0]  "x86_coreid_bits").
Comment 3 Mark Wielaard 2019-07-27 14:29:54 UTC
(In reply to Changbin Du from comment #1)
> BTW, the latest master branch has build failure.
> 
>   CCLD     libebl_sparc.so
>   CCLD     libebl_ppc.so
>   CCLD     libebl_ppc64.so
>   CCLD     libebl_s390.so
>   CCLD     libebl_tilegx.so
>   CCLD     libebl_m68k.so
>   CCLD     libebl_bpf.so
>   AR       libebl_riscv_pic.a
>   CCLD     libebl_riscv.so
> /usr/bin/ld: libebl_riscv_pic.a(riscv_init.os): relocation R_X86_64_PC32
> against undefined hidden symbol `riscv64_core_note' can not be used when
> making a shared object
> /usr/bin/ld: final link failed: nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile:1299: libebl_riscv.so] Error 1
> make[1]: *** [Makefile:486: all-recursive] Error 1
> make: *** [Makefile:402: all] Error 2

That is surprising, obviously that doesn't happen on any of the buildbots. You might want to open a different bug for this issue (because it seems totally unrelated to this issue) explaining how you configured, which gcc and ld versions you are using and maybe the output of make V=1 to show the command line flags (also make sure you make distclean first).
Comment 4 Frank Ch. Eigler 2020-01-10 15:14:26 UTC
as per comment #3, the test was based on a misunderstanding of the libdw api