Bug 1255402 - debugedit corrupts compilation unit names
debugedit corrupts compilation unit names
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rpm (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Florian Festi
BaseOS QE Security Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-20 09:37 EDT by Roman Kagan
Modified: 2017-07-13 05:45 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-13 05:45:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Roman Kagan 2015-08-20 09:37:30 EDT
Description of problem:

Under certain circumstances debugedit corrupts the names of compilation units.


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

rpm-build-4.11.1-16.el7.x86_64
(actually all RHEL6 and RHEL7 and a number of Fedora releases)


How reproducible: 100%

Steps to Reproduce:
1. create two source files, with the name of one being a tail substring of the other:

# cat very_long_name.c 
extern int foo(int);

main()
{
        return foo(10);
}
# cat subdir/another_very_long_name.c 
int foo(int i)
{
        return i;
}


2. compile the file named the substring without directory, and the one names the full string with the full path, then link both into one executable:

# gcc -g -c very_long_name.c                                  
# gcc -g -c $PWD/subdir/another_very_long_name.c 
# gcc -g -o executable very_long_name.o another_very_long_name.o 


3. check the compile unit paths:

# readelf -wi executable | fgrep -A4 compile_unit | fgrep name
    <11>   DW_AT_name        : (indirect string, offset: 0x92): very_long_name.c
    <63>   DW_AT_name        : (indirect string, offset: 0x68): /home/rkagan/debugedit-bug/subdir/another_very_long_name.c


4. run debugedit against the executable

# /usr/lib/rpm/debugedit -b $PWD -d /usr/src/debug executable

5. check the compile unit paths:

# readelf -wi executable | fgrep -A4 compile_unit | fgrep name   
    <11>   DW_AT_name        : (indirect string, offset: 0x92): me.c
    <63>   DW_AT_name        : (indirect string, offset: 0x68): /usr/src/debug/subdir/another_very_long_name.c


Actual results:

the shorter name is corrupt

Expected results:

the names remain valid


Additional info:

The problem is that, as can be seen from the offsets on step 3, the linker optimizes the storage for strings in .debug_str section, and makes the compilation unit name of the former file to be physically a substring of the latter.

Now when debugedit rewrites in place the name of the latter, it corrupts that of the former.

The scenario is not as unlikely as it may seem: we've encountered it when building Qt-based applications, in the following -- very common -- pattern:

for a class SomeClass we had

  - SomeClass.h - header defining a QOBJECT-derived class
  - SomeClass.cpp - C++ source with the implementation of the class; it was compiled locally (with no path prepended)
  - moc_SomeClass.cpp - Qt meta-object-related definitions for class SomeClass, generated from SomeClass.h with moc; it was compiled by absolute path

then the resulting executable had the compilation unit name for SomeClass.cpp being a substring of that for /full/path/to/moc_SomeClass.cpp, so debugedit, when run against the executable, would corrupt the name for SomeClass.cpp.
Comment 2 Florian Festi 2017-07-13 05:45:46 EDT
This issue is now fixed upstream by rewriting large parts of the debugedit tool. Unfortunately the changes are too invasive to be back ported to the RHEL 7 version of rpm. Closing.

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