On Fri, 2014-10-24 at 18:33 -0700, Sukadev Bhattiprolu wrote: > We have some code in the perf tool[1] that uses following > sequence of calls to try and determine if the return address > for a function is in the link register (LR) or on the stack: > > dwfl = dwfl_begin(&offline_callbacks); > > dwfl_report_offline(dwfl, "" exec_file, -1); > > mod = dwfl_addrmodule(dwfl, pc); > > dwfl_module_eh_cfi(mod, &bias); > > /* etc.. */ > > where: exec_file is > > /usr/lib64/power8/libc-2.17.so (on RHEL7) > /usr/lib64/libc-2.18.so (on Fedora20) > > and 'pc' is an address in libc, say in vfprintf(), rand() etc. > > This sequence of calls works consistently on Fedora20 and fails > consistently on RHEL7 - where dwfl_addrmodule() returns -1 > (dwfl_errmsg() says "no error").
That should only happen when dwfl == NULL (in which case there should be an earlier error), or no module contains the given address. > The versions of elfutils, glibc, gcc are slightly different > between the two and I have listed them below [2][3][4]. > > Is there a difference in the way libc or debug info is > organized between F20 and RHEL7 ? I don't believe so. But clearly these are two completely different glibc versions. > The Fedora20 is a Power7 system and RHEL7 is a Power8. > > With some debug statements, I see that in dwfl_addrsegment(): > > lookup() retruns 1, > dwfl->lookup_module is non-null > dwfl_addrsegment() returns -1. > > I can collect more debug if necessary. Could you find out what the module load address is for the Dwfl_Module you create through dwfl_report_offline? dwfl_module_info will give you the start and end address range. And what is the pc value you provide to dwfl_addrmodule in both cases? Thanks, Mark
