[Bug ld/17212] Tag_CPU_name merging produces wrong tag.
Hi, I tried to compile a binary optimized for ARM Cortex-A15 with ARM Cortex-A8 cross-toolchain (host is x86_64-pc-linux-gnu), but Tag_CPU_name appears to be "Cortex-A8" for the binary instead of "Cortex-A15". The example session follows: $ arm-v7a8-linux-gnueabi-gcc -O2 -mcpu=cortex-a15 divtest.c -o divtest.a15 $ readelf -A divtest.a15 Attribute Section: aeabi File Attributes Tag_CPU_name: "Cortex-A8" Tag_CPU_arch: v7 Tag_DIV_use: Allowed in v7-A with integer division extension After some investigation I found out, that Tag_CPU_name merging based on Tag_CPU_arch. Since the first file to appear during linking is crt1.o, which has Tag_CPU_name: "Cortex-A8" for A8 toolchain, the result binary's Tag_CPU_name is also "Cortex-A8". Is this expected behavior of ld, or maybe tags should be merged to a more specific "Cortex-A15"? Perhaps we should use Tag_DIV_use when merging names? -Maxim ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: secureplt breaks ld on Alpha Linux
On Sun, 31 Aug 2014, Richard Henderson wrote: > On 08/30/2014 06:46 AM, Mikulas Patocka wrote: > > The only possibility to save them is in the code at the beginning of > > _PROCEDURE_LINKAGE_TABLE_ - do you think it would be possible to save the > > registers on the stack here? Or, would it cause unwind problems? > > It wouldn't work. Yes. I would also break __builtin_return_address. > > What exactly these anotations do? Do they turn off lazy binding? > > Yes. Other examples include _mcount, and the division routines. > > r~ So, what exactly should be done? Can we hack ld so that if filename is "libots.so", lazy binding for symbols in this library is turned off automatically? Mikulas ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: secureplt breaks ld on Alpha Linux
On 09/01/2014 08:09 AM, Mikulas Patocka wrote: > So, what exactly should be done? Can we hack ld so that if filename is > "libots.so", lazy binding for symbols in this library is turned off > automatically? Not hack ld.so. Modify the libots.so binary such that _OtsZero is STT_NOTYPE. The linker will not create a plt entry unless the symbol is STT_FUNC. I see that most of the _Ots symbols are already NOTYPE. I wonder if this is intentional and _OtsZero just got forgotten, or if it's a happy oversight in that they forgot to annotate them entirely. r~ ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/17334] New: compilation of blackfin toolchain fails
https://sourceware.org/bugzilla/show_bug.cgi?id=17334 Bug ID: 17334 Summary: compilation of blackfin toolchain fails Product: binutils Version: 2.24 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: wbx at openadk dot org Hi, I use buildroot to create a cross-toolchain targeting blackfin. Default is the usage of gcc 4.5.4 and binutils 2.22. This works fine. When I reconfigure to use binutils 2.23.2 or binutils 2.24 the build fails with a log of failures like this one: bfin-buildroot-linux-uclibc/bin/ld: fde encoding in _divdi3_s.o(.eh_frame) prevents .eh_frame_hdr table being created. Seems like a regression or do we need some special options for gcc when switching to a newer binutils version? I can provide full logs, if required. Thanks in advance Waldemar -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: secureplt breaks ld on Alpha Linux
On Mon, 1 Sep 2014, Richard Henderson wrote: > On 09/01/2014 08:09 AM, Mikulas Patocka wrote: > > So, what exactly should be done? Can we hack ld so that if filename is > > "libots.so", lazy binding for symbols in this library is turned off > > automatically? > > Not hack ld.so. > > Modify the libots.so binary such that _OtsZero is STT_NOTYPE. The linker will > not create a plt entry unless the symbol is STT_FUNC. > > I see that most of the _Ots symbols are already NOTYPE. I wonder if this is > intentional and _OtsZero just got forgotten, or if it's a happy oversight in > that they forgot to annotate them entirely. > > r~ It is legally questionable if we can redistribute the modified library. Even if I could distribute it, where would I upload it so that other people will find it? Obviously I can't upload it to ftp.compaq.com where the compiler is located. So, I think a better solution would be to change ld so that it would recognize "libots.so" filename and act as if symbols in this file were defined with STT_NOTYPE attribute. Or, turn off that "secure plt" feature at all if "libots.so" is used - Alpha is so rare that I doubt anybody will put any effort into writing exploits for Alpha. Mikulas ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
