Bug 1255402

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.