This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug translator/16676] Inconsistently-biased addresses for ET_EXEC


https://sourceware.org/bugzilla/show_bug.cgi?id=16676

--- Comment #2 from Josh Stone <jistone at redhat dot com> ---
Consider:

$ ./stap -e 'probe process.plt("strstr"),process.function("_start") {next}' -c
/usr/bin/ls --poison-cache -p2
# probes
process("/usr/bin/ls").statement(0x402c00) /* pc=.absolute+0x2c00 */ /* <-
process("/usr/bin/ls").plt("strstr").statement(0x402c00) */
process("/usr/bin/ls").function("_start") /* pc=.dynamic+0x4e3c */ /* <-
process("/usr/bin/ls").plt("strstr"),process("/usr/bin/ls").function("_start")
*/

In one run, we changed our mind from .absolute to .dynamic!?!

We make this decision in dwflpp::relocate_address, which looks at
dwfl_module_relocations().  That function will return 0 if mod->e_type is
ET_EXEC, or 1 if mod->e_type is ET_DYN.  And sure enough, the e_type is
changing in the middle of this run.  A hardware watchpoint tells me where:

libdwfl/dwfl_module_getdwarf.c 
 134â   mod->e_type = ehdr->e_type;
 135â
 136â   /* Relocatable Linux kernels are ET_EXEC but act like ET_DYN.  */
 137â   if (mod->e_type == ET_EXEC && file->vaddr != mod->low_addr)
 138â>    mod->e_type = ET_DYN;

(gdb) bt
#0  0x000000370481dc4b in open_elf (file=file@entry=0x2185be0, mod=<optimized
out>, mod=<optimized out>) at dwfl_module_getdwarf.c:138
#1  0x000000370481e4b1 in find_aux_sym (aux_strshndx=<synthetic pointer>,
aux_xndxscn=<synthetic pointer>, aux_symscn=<synthetic pointer>, mod=0x2185b60)
at dwfl_module_getdwarf.c:907
#2  find_symtab (mod=mod@entry=0x2185b60) at dwfl_module_getdwarf.c:1022
#3  0x000000370481ee8e in dwfl_module_getsymtab (mod=0x2185b60) at
dwfl_module_getdwarf.c:1259
#4  0x00000000004e4c24 in symbol_table::get_from_elf (this=0x2188fb0) at
../tapsets.cxx:7806

So when it opened the aux minisymtab (.gnu_debugdata), this triggered a kernel
heuristic that really should not apply to this case.  FWIW, file->vaddr =
0x400020, and mod->low_addr = 0x400000.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]