Bug 444249 - elf_find_unit() has issues with split debug info if start addresses differ
Summary: elf_find_unit() has issues with split debug info if start addresses differ
Status: RESOLVED FIXED
Alias: None
Product: TCF
Classification: Tools
Component: Agent (show other bugs)
Version: 1.3   Edit
Hardware: PC Linux
: P2 major (vote)
Target Milestone: 1.3   Edit
Assignee: Project Inbox CLA
QA Contact: Eugene Tarassov CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-16 08:32 EDT by Anton Leherbauer CLA
Modified: 2015-06-16 03:17 EDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Leherbauer CLA 2014-09-16 08:32:51 EDT 
Usually a separate (split) debug object file should have the same start address as the object it is derived from, but this is not the case if a library gets prelinked after debug info has been split out (see also https://bugs.kde.org/show_bug.cgi?id=185816).

This address mismatch causes a failure to lookup symbols and line info because elf_find_unit() cannot locate the compilation unit for an address.

E.g. consider the diffs between libc-2.19.so and its debug info file:

/lib64/libc-2.19.so:     file format elf64-x86-64
architecture: i386:x86-64, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x0000003c02a20120

Program Header:
    PHDR off    0x0000000000000040 vaddr 0x0000003c02a00040 paddr 0x0000003c02a00040 align 2**3
         filesz 0x0000000000000230 memsz 0x0000000000000230 flags r-x
  INTERP off    0x0000000000170800 vaddr 0x0000003c02b70800 paddr 0x0000003c02b70800 align 2**4
         filesz 0x000000000000001c memsz 0x000000000000001c flags r--
    LOAD off    0x0000000000000000 vaddr 0x0000003c02a00000 paddr 0x0000003c02a00000 align 2**21
         filesz 0x00000000001a41c4 memsz 0x00000000001a41c4 flags r-x
    LOAD off    0x00000000001a4570 vaddr 0x0000003c02da4570 paddr 0x0000003c02da4570 align 2**21
         filesz 0x0000000000005350 memsz 0x0000000000009a50 flags rw-


/lib64/.debug/libc-2.19.so:     file format elf64-x86-64
architecture: i386:x86-64, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x0000000000020120

Program Header:
    PHDR off    0x0000000000000040 vaddr 0x0000000000000040 paddr 0x0000000000000040 align 2**3
         filesz 0x0000000000000230 memsz 0x0000000000000230 flags r-x
  INTERP off    0x0000000000000290 vaddr 0x0000000000170800 paddr 0x0000000000170800 align 2**4
         filesz 0x0000000000000000 memsz 0x000000000000001c flags r--
    LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**21
         filesz 0x0000000000000290 memsz 0x00000000001a41c4 flags r-x
    LOAD off    0x00000000001a4570 vaddr 0x00000000003a4570 paddr 0x00000000003a4570 align 2**21
         filesz 0x0000000000000000 memsz 0x0000000000009a50 flags rw-
Comment 1 Martin Oberhuber CLA 2014-09-17 14:33:30 EDT 
Marking MAJOR since this issue makes debug and analysis of the most significant sharedlibs impossible when they are prelinked.
Comment 2 Eugene Tarassov CLA 2014-09-18 13:37:30 EDT 
Fixed.
Thanks!
Comment 3 Martin Oberhuber CLA 2014-09-18 14:20:14 EDT 
https://git.eclipse.org/c/tcf/org.eclipse.tcf.agent.git/commit/?id=7c2c611f8841f8dea81d83eed83b730bee5cc37e

I see that the fix needed significant code changes ; thanks very much for the quick turnaround, Eugene !

Bug 443084 has been backported to 1.2_luna for split debug info, do you think that this fix is safe to also backport or is it too big / risky ?
Comment 4 Eugene Tarassov CLA 2014-09-18 16:07:26 EDT 
I think it is too risky to backport. Technically, it is new feature. Before this, we did not support files that were re-linked to a different address *after* debug info was moved to a separate file. It is miracle that the debug info is still usable after such brutal handling, and my confidence in this code is rather low.