Bug 165598 - libdwfl performs relocation twice
Summary: libdwfl performs relocation twice
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: elfutils
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Roland McGrath
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-08-10 17:54 UTC by Frank Ch. Eigler
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version: 0.113-2
Clone Of:
Environment:
Last Closed: 2005-08-14 21:58:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Frank Ch. Eigler 2005-08-10 17:54:54 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc3 Firefox/1.0.6

Description of problem:
dwarf_fromaddr sometimes seems to misinterpret attribute data

Version-Release number of selected component (if applicable):
0.112-0.1

How reproducible:
Always

Steps to Reproduce:
when siccing libdwfl/libdw onto a kernel module (such as say ext3.ko) for a dwarf_func_entrypc the library will likely encounter a very small address.  In the 2.6.12-1.1372FC3 kernel's case, "read_block_bitmap" is at offset 0xac.

When dwarf_func_entrypc is called on this symbol, it successfully finds attr#17 in the debug info, and dwarf_attr finds the debuginfo with this 0xac address there.  Trouble is, dwarf_fromaddr treats the returned byte pointer as a decoded 4- or 8-byte value, rather than uleb128.  So it copies junk onto the caller's return_addr, leading to much chaos and mayhem.

Actual Results:  dwarf_fromaddr should return 0x000000000000ac for this case, and thence all should be well.

Additional info:

Comment 1 Roland McGrath 2005-08-10 18:35:36 UTC
DW_FORM_addr items are not encoded in LEB128 format.
Please give a test case, rather than an analysis of internal issues.

Comment 2 Frank Ch. Eigler 2005-08-10 19:15:39 UTC
% ./dwflmodtest -k | grep mii | grep link_ok
drivers/net/mii.c:211: mii_link_ok: 0xf104c468..0xf104c48f => 0xf104c468

these numbers appear to belong to a parallel dimension, since I would expect
either 468 or f8826468.

% nm sez:
00000468 T mii_link_ok
% grep mii /proc/modules
mii 9537 1 epic100, Live 0xf8826000


Comment 3 Roland McGrath 2005-08-10 22:13:11 UTC
The initial analysis had nothing to do with the real problem.
The values were off by exactly the module's load address (wrapped around).
This was because libdwfl was performing the same relocation pass twice on the
same data.  I've fixed the bug.

Comment 4 Frank Ch. Eigler 2005-08-12 19:21:55 UTC
Where can one find a fixed elfutils release?

Comment 5 Frank Ch. Eigler 2005-08-14 13:14:27 UTC
elfutils-1.113-2 in rawhide fixes this bug.

Comment 6 Roland McGrath 2005-08-14 21:58:31 UTC
Oops.  I forgot to put the bug number in the rpm changelog.


Note You need to log in before you can comment on or make changes to this bug.