[Bug ld/19623] regression: missing relocation for symbols in discarded section
https://sourceware.org/bugzilla/show_bug.cgi?id=19623 --- Comment #2 from winter-...@bfw-online.de --- Hi Nick, so it is quite hard to make up the scenario as one needs to design a COFF structure just like the problematic one. Maybe debugging the linker can resolve this more quickly. While debugging the linker (recent version at commit 33b4777ca1b) I verified some of my claims. It now appears that a) the macro discarded_section (sec) on sec returns false because bfd_is_abs_section (sec) is true, so no "continue" statement happens b) if one adds "sec->output_section->vma == 0" as entry condition for the branch, the call of _bfd_clear_contents has an impact on the resulting relocation address (being wrong, but still somewhat changed from the original state) > This intrigues me, and I suspect is the core of the problem. In fact, actually there seem to be two problems (a, b). > Do you have any > idea as to why this should make a difference ? On the surface the purpose > seems > clear: the reloc being cleared references a section that is going to be > discarded. so there is no point in processing, or retaining, the reloc. Well, my understanding of the code and the COFF structure in general is somewhat limited and I am having a hard time understanding why the error occurs and what exactly the error is since the current "fix" is to continue the loop execution which actually prevents a call to _bfd_final_link_relocate in line 3107. Yet the resulting broken file seems like an object file where relocation did not occur. How could the "continue" statement in the block for handling discarded sections trigger a relocation when the code indicates the opposite? > Please do try - I think that we are going to need one. > > If we are going to have to make an SCO specific patch, (which is > undesirable, but appears to be the case in this situation), then we will > need a way to make > sure that it works, and that it does not break other COFF targets. Sure, I will keep trying to create a minimal test case. For now I will attach some debug logs so the internal state at the erroneous situation is visible and might gain some insights. In my first post I suggested that one function of my two functions was relocated correctly or luckily did not require relocation and this stayed functional. I discovered that the symbols of the functions have different storage classes which might have an impact on relocation: [ 13](sec 1)(fl 0x00)(ty 0)(scl 6) (nx 0) 0x6af4 foo_patch [121](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x6b0c bar_patch Regards, Leon -- 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
[Bug ld/19623] regression: missing relocation for symbols in discarded section
https://sourceware.org/bugzilla/show_bug.cgi?id=19623 --- Comment #3 from winter-...@bfw-online.de --- Created attachment 9034 --> https://sourceware.org/bugzilla/attachment.cgi?id=9034&action=edit gdb session with ld -- 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
[Bug ld/19623] regression: missing relocation for symbols in discarded section
https://sourceware.org/bugzilla/show_bug.cgi?id=19623 --- Comment #4 from winter-...@bfw-online.de --- Reading further in the source code (and guessing a lot) maybe the we have a section named A with VMA = 0 which means it requires no immediate relocation. Later on when the linker adds new object files, it adds sections and suddenly the section A gets a VMA != 0 for some reason. Then the symbols in section A would need to be relocated. In the old code (or new code with the "fix") the linker will see that section A has VMA = 0 and will skip relocations in the first pass. Later once VMA != 0 it will relocate such symbols. The result is a binary with all symbols perfectly relocated. In the new code the linker will not detect the special case of VMA = 0 and will relocate immediately. Since VMA = 0 the relocation will have no effect. Yet since relocation was done, flag for further relocations is cleared (if there is such a flag), not sure. Later on, section A gets a VMA != 0. The linker will ignore the section since it has already done relocation. The result is a binary with some symbols not relocated. Browsing the code I have not found whether a successful relocations sets a flag to prevent further relocations, yet the story could explain the different results the way I see them. Also I cannot explain why clearing the contents does affect the result in the way it does. Maybe my explanation model is incomplete (or completely wrong). -- 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
[Bug binutils/19698] [2.26 Regression] mysql qt4 driver plugin not able to open libmysqlclient.so
https://sourceware.org/bugzilla/show_bug.cgi?id=19698 Richard Guenther changed: What|Removed |Added CC||rguenth at gcc dot gnu.org -- 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
[Bug ld/19719] New: Mixing PIC and non-PIC input files generates unexpected result
https://sourceware.org/bugzilla/show_bug.cgi?id=19719
Bug ID: 19719
Summary: Mixing PIC and non-PIC input files generates
unexpected result
Product: binutils
Version: 2.27 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: x86
[hjl@gnu-6 weak-4]$ cat foo.c
extern int __attribute__ ((weak)) fun (void);
int
foo (void)
{
if (&fun != 0)
return fun ();
return 0;
}
[hjl@gnu-6 weak-4]$ cat bar.c
extern int __attribute__ ((weak)) fun (void);
int
bar (void)
{
if (&fun != 0)
return fun ();
return 0;
}
[hjl@gnu-6 weak-4]$ cat main.c
#include
extern int foo (void);
extern int bar (void);
int
main (void)
{
if (foo () != bar ())
abort ();
return 0;
}
[hjl@gnu-6 weak-4]$ cat fun1.c
/* Dummy */
[hjl@gnu-6 weak-4]$ cat fun2.c
int
fun (void)
{
return 20;
}
[hjl@gnu-6 weak-4]$ make
gcc -B./ -O2 -c -o foo.o foo.c
gcc -B./ -O2 -fPIC -c -o bar.o bar.c
gcc -B./ -O2 -c -o main.o main.c
gcc -B./ -shared -Wl,-soname,libfun.so -fPIC -O2 -o libfun1.so fun1.c
gcc -B./ -shared -Wl,-soname,libfun.so -fPIC -O2 -o libfun2.so fun2.c
ln -sf libfun1.so libfun.so
gcc -B./ -O2 -o x foo.o bar.o main.o libfun.so -Wl,-R,.
ln -sf libfun1.so libfun.so
./x
ln -sf libfun2.so libfun.so
./x
Makefile:20: recipe for target 'all' failed
make: *** [all] Aborted
[hjl@gnu-6 weak-4]$
--
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
[Bug ld/19579] [Regression] link error linking fortran code on s390x-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=19579
--- Comment #4 from Matthias Klose ---
Breakpoint 1, xexit (code=1) at ../../libiberty/xexit.c:48
48 {
(gdb) bt
#0 xexit (code=1) at ../../libiberty/xexit.c:48
#1 0x02aa00025020 in ldwrite () at ../../ld/ldwrite.c:590
#2 0x02aa000237a4 in main (argc=41, argv=0x3fff768) at
../../ld/ldmain.c:430
test case at
http://people.canonical.com/~doko/tmp/s390x-tst2.tar.xz
--
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
[Bug ld/19480] [2.26.51 regression] ld creates wrong output for libstdc++6.dll for mingw32 (32-bit)
https://sourceware.org/bugzilla/show_bug.cgi?id=19480 Nick Clifton changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Nick Clifton --- Hi Stephen, > -Wl,--no-gc-sections produces a working libstdc++-6.dll for me (with a ld > built with the PE/COFF GC patch). OK, so that is good to know. > I was wondering whether this could be due to a missing section name in > pe.sc, but the fact that this is 32-bit specific suggests there's something > else going on, right? With both DLLs to hand, how could I go about figuring > out what went wrong? (The "bad" DLL has a bunch of undefined symbols.) The undefined symbols are almost certainly the key. They probably should not be undefined. First of all, please try out the patch that I am about to upload. It may be that the problem is that the linker is garbage collecting sections that are really needed, because the linker script failed to mark those sections as KEEP. (You may need to check that the linker script you are using is the one that is fixed by the uploaded patch. Add -Wl,--verbose to the gcc command line to check this). If that does not work then try adding -Wl,--print-gc-sections to the bad DLL creation command line. See what gets thrown away, see if this matches up with the undefined symbols, and try to work out why they are being thrown away. Cheers Nick -- 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
[Bug ld/19480] [2.26.51 regression] ld creates wrong output for libstdc++6.dll for mingw32 (32-bit)
https://sourceware.org/bugzilla/show_bug.cgi?id=19480 --- Comment #5 from Nick Clifton --- Created attachment 9035 --> https://sourceware.org/bugzilla/attachment.cgi?id=9035&action=edit Update PE linker script to KEEP more sections -- 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
[Bug binutils/19721] New: [libopcodes] [Aarch64] Incorrect aliasing for ORR instruction
https://sourceware.org/bugzilla/show_bug.cgi?id=19721 Bug ID: 19721 Summary: [libopcodes] [Aarch64] Incorrect aliasing for ORR instruction Product: binutils Version: 2.26 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: njholcomb at wi dot rr.com Target Milestone: --- The libopcodes decoder for aarch64 incorrectly aliases ORR instructions with the zero register but non-zero shift values to MOV instructions without signifying the shift. Below is GDB output with register info after executing one such instruction (0xaa1167e): (gdb) x/x 0x400588 0x400588 : 0xaa1167e (gdb) x/i $pc => 0x400588 : mov x7, x17 (gdb) info registers ... x7 0x83322 ... x170x4109d8 ... (gdb) stepi 0x0040058c in main () (gdb) info registers ... x7 0x8213b000 ... x170x4109d8 ... The instruction correct interpretation should be the ORR instruction with a left shift of 25 bits. -- 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
[Bug binutils/19722] New: [libopcodes] [Aarch64] Undefined SIMD instruction not marked undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=19722 Bug ID: 19722 Summary: [libopcodes] [Aarch64] Undefined SIMD instruction not marked undefined Product: binutils Version: 2.26 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: njholcomb at wi dot rr.com Target Milestone: --- Pair word instruction, like ldpsw, are undefined if the address for loading is specified in a register also used as a destination register. One example from libopcodes is: ldpsw x12, x6, [x6],#-8 >From the bytes: 0x68ea18cc In this case, x6 is both a destination for the load, as well as supplying the address for the load, which should be undefined. -- 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
[Bug binutils/19698] [2.26 Regression] mysql qt4 driver plugin not able to open libmysqlclient.so
https://sourceware.org/bugzilla/show_bug.cgi?id=19698 --- Comment #18 from dura --- I can confirm that building mariadb with binutils-2.26, with your patch and without 422f11824b3abf6c71042e2ee3aed572f250fc89422f11824b3abf6c71042e2ee3aed572f250fc89 reversed produce a libmysqlclient.so that does not show double default mysql_real_connect and is usable by akonadiserver. -- 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
[Bug binutils/19698] [2.26 Regression] mysql qt4 driver plugin not able to open libmysqlclient.so
https://sourceware.org/bugzilla/show_bug.cgi?id=19698 --- Comment #19 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0f550b3df1d4ae31d12505cf93981313c9c6dd25 commit 0f550b3df1d4ae31d12505cf93981313c9c6dd25 Author: H.J. Lu Date: Wed Feb 24 15:13:35 2016 -0800 Update symbol version for symbol from linker script We need to update symbol version for symbols from linker script. bfd/ PR ld/19698 * elflink.c (bfd_elf_record_link_assignment): Set versioned if symbol version is unknown. ld/ PR ld/19698 * testsuite/ld-elf/pr19698.d: New file. * testsuite/ld-elf/pr19698.s: Likewise. * testsuite/ld-elf/pr19698.t: Likewise. -- 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
[Bug ld/19724] New: linker script support of (hidden) "FOO@BAR" = foo; is broken
https://sourceware.org/bugzilla/show_bug.cgi?id=19724
Bug ID: 19724
Summary: linker script support of (hidden) "FOO@BAR" = foo; is
broken
Product: binutils
Version: 2.27 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: glebfm at altlinux dot org
Target Milestone: ---
$ echo 'BAR {global:FOO; local:*;};' > exports
$ echo '"FOO@BAR" = foo;' > libfoo.lds
$ echo 'int foo() {return 0;}' > libfoo.c
$ gcc -s -shared -fPIC libfoo.c -Wl,--version-script,exports -Wl,libfoo.lds -o
libfoo.so
$ readelf -Ws libfoo.so | grep FOO
8: 05c0 0 FUNCGLOBAL DEFAULT 11 FOO@@BAR
$ echo 'int main() {return FOO();}' > foo.c
$ gcc -L$PWD foo.c -o foo -lfoo -Wno-implicit-function-declaration
$ LD_LIBRARY_PATH=$PWD ./foo
./foo: relocation error: ./foo: symbol FOO, version BAR not defined in file
libfoo.so with link time reference
I bisected it to:
6e33951edcbed1fd803beabcde2af3b252b92164 is the first bad commit
commit 6e33951edcbed1fd803beabcde2af3b252b92164
Author: H.J. Lu
Date: Fri Aug 7 05:04:21 2015 -0700
Properly merge hidden versioned symbol
...
--
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
[Bug ld/19724] linker script support of (hidden) "FOO@BAR" = foo; is broken
https://sourceware.org/bugzilla/show_bug.cgi?id=19724 Gleb Fotengauer-Malinovskiy changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Gleb Fotengauer-Malinovskiy --- Already fixed: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=0f550b3df1d4ae31d12505cf93981313c9c6dd25 *** This bug has been marked as a duplicate of bug 19698 *** -- 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
[Bug binutils/19698] [2.26 Regression] mysql qt4 driver plugin not able to open libmysqlclient.so
https://sourceware.org/bugzilla/show_bug.cgi?id=19698 Gleb Fotengauer-Malinovskiy changed: What|Removed |Added CC||glebfm at altlinux dot org --- Comment #20 from Gleb Fotengauer-Malinovskiy --- *** Bug 19724 has been marked as a duplicate of this bug. *** -- 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
[Bug ld/19623] regression: erroneous relocation for symbols in absolute section (vma == 0)
https://sourceware.org/bugzilla/show_bug.cgi?id=19623 winter-...@bfw-online.de changed: What|Removed |Added Summary|regression: missing |regression: erroneous |relocation for symbols in |relocation for symbols in |discarded section |absolute section (vma == 0) --- Comment #5 from winter-...@bfw-online.de --- I checked the offsets of the symbols in the original file and the output files (in broken and fine versions) and found that the problem is probably the inverse of what I suspected, I know assume that this problem is not a missing relocation but a relocation that happens even though it should not. The original file has relative jumps to the target destination which should stay exactly the same when the sections are not to be reordered. The machine code ought to stay exactly the same in the resulting binary. The old version of ld skipped relocation for the symbols at hand so there was no relocation and everything was untouched and fine. The new version of ld does compute relocation and changes the jump targets. Unfortunately the computed relocated addresses differ from the original ones which is wrong. Reading this web site [1] it seems symbols in absolute section should not be relocated, yet it happens (wrongfully) in our scenario. [1] ftp://ftp.gnu.org/old-gnu/Manuals/gas/html_chapter/as_4.html -- 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
