Shared objects which should be PIC aren't
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gcc |
Fix Released
|
Critical
|
|||
binutils (Ubuntu) |
Fix Released
|
Undecided
|
Matthias Klose | ||
Karmic |
Fix Released
|
Undecided
|
Matthias Klose | ||
eglibc (Ubuntu) |
Fix Released
|
Undecided
|
Matthias Klose | ||
Karmic |
Fix Released
|
Undecided
|
Matthias Klose | ||
gcc-4.4 (Ubuntu) |
Fix Released
|
Undecided
|
Matthias Klose | ||
Karmic |
Fix Released
|
Undecided
|
Matthias Klose |
Bug Description
Binary package hint: gcc-4.4
Hi
Since it's built with gcc-4.4, eglibc isn't PIC anymore; just like almost all shared objects we built.
Debian noticed this issue when considering the gcc-4.4 switch:
http://
and the eglibc testsuite has test check-textrel.out which fails since it's not PIC anymore.
The issue is in gcc-4.4 which generates the wrong type of ELF data for exception handling (eh_frame).
This prompts for a rebuild of a bunch of packages between beta and final with a fixed toolchain.
A workaround is to build things with -fno-dwarf2-
We should also patch gcc-4.4 to default to setting this flag on ARM EABI:
http://
See also PR40521 which is an issue in gas that prevents the proper fix in gcc.
We should include this patch in our gcc-4.4 ASAP and rebuild the toolchain against it.
Changed in binutils (Ubuntu Karmic): | |
assignee: | nobody → Matthias Klose (doko) |
Changed in eglibc (Ubuntu Karmic): | |
assignee: | nobody → Matthias Klose (doko) |
Changed in gcc: | |
status: | Unknown → New |
Changed in binutils (Ubuntu Karmic): | |
status: | Fix Released → In Progress |
Changed in gcc: | |
status: | New → Fix Released |
Changed in gcc: | |
importance: | Unknown → Critical |
Put this in main.c and build it with a 4.4-branch compiler using recent binutils:
int main ()
{
return 0;
}
Versions:
GNU assembler (GNU Binutils) 2.19.51.20090611 linux-gnu- gcc (GCC) 4.4.1 20090611 (prerelease)
i686-pc-
% i686-pc- linux-gnu- gcc -c main.c; objdump --wide -h main.o | grep ALLOC
0 .text 0000000a 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000000 00000000 00000000 00000040 2**2 CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000040 2**2 ALLOC
% i686-pc- linux-gnu- gcc -c -g main.c; objdump --wide -h main.o | grep ALLOC
0 .text 0000000a 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000000 00000000 00000000 00000040 2**2 CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000040 2**2 ALLOC
12 .eh_frame 00000034 00000000 00000000 000001c0 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
We're using GAS's .cfi_startproc et cetera directives to generate debug information. But they only generate .eh_frame, not .debug_frame.
I also noticed this problem on an ARM EABI target. ARM EABI does not use .eh_frame, only .debug_frame and .ARM.exidx.
The easiest fix is to disable use of the CFI directives when we are trying to generate .debug_frame. I believe GCC used to generate both .debug_frame and .eh_frame for the same function. If we want both to gain the advantages of using CFI directives (e.g. potentially accurate across inline asm), then we need to teach gas to emit .debug_ frame/. eh_frame/ both as requested.