Hide Forgot
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:
DW_FORM_addr items are not encoded in LEB128 format. Please give a test case, rather than an analysis of internal issues.
% ./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
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.
Where can one find a fixed elfutils release?
elfutils-1.113-2 in rawhide fixes this bug.
Oops. I forgot to put the bug number in the rpm changelog.