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

["jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

            Bug ID: 16676
           Summary: Inconsistently-biased addresses for ET_EXEC
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: jistone at redhat dot com

We seem to have inconsistent bias behavior for the build-id in ET_EXEC, and the
problem seems to be from missing debuginfo.  Note that prelink is often another
culprit of bias issues, but I did "prelink -u" for these first.


For my first point of comparison, consider ET_DYN /usr/bin/stap, whether or not
I have systemtap-debuginfo installed:

  $ stap -e 'probe process.plt {next}' -c /usr/bin/stap \
    -p3 -vv --poison-cache |& grep build-id
  Found build-id in /usr/bin/stap, length 20, start at 0x284

For relocatable binaries, it's reasonable that we'd get a plain file offset.


Now ET_EXEC /usr/local/bin/stap, with debuginfo baked in:

  $ stap -e 'probe process.plt {next}' -c /usr/local/bin/stap \
    -p3 -vv --poison-cache |& grep build-id
  Found build-id in /usr/local/bin/stap, length 20, start at 0x400284

It's not relocatable, and now we have an absolute address, ok.


Now ET_EXEC /usr/bin/ls without coreutils-debuginfo:

  $ stap -e 'probe process.plt {next}' -c /usr/bin/ls \
    -p3 -vv --poison-cache |& grep build-id
  Found build-id in /usr/bin/ls, length 20, start at 0x284

So that's inconsistent -- not relocatable, but it's a file offset.


Now ET_EXEC /usr/bin/ls *with* coreutils-debuginfo:

  $ stap -e 'probe process.plt {next}' -c /usr/bin/ls \
    -p3 -vv --poison-cache |& grep build-id
  Found build-id in /usr/bin/ls, length 20, start at 0x400284

We got the absolute address back!


That "Found build-id" line is in translate.cxx dump_build_id().  In a debugger
I can see that dwfl_module_build_id() is giving 0x400284 either way, but when
debuginfo is missing, the dwfl_module_relocate_address() kills the absolute
bias.

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