[Bug ld/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation

2016-08-30 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20475 --- Comment #10 from whitequark at whitequark dot org --- Unfortunately the problem resists my attempts to write a minimal testcase. I do not have any more time to spend debugging this, although I will gladly test any suggestions. As a fix, I

[Bug ld/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation

2016-08-30 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20475 whitequark at whitequark dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED

[Bug ld/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation

2016-08-20 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20475 --- Comment #6 from whitequark at whitequark dot org --- I've verified that your suggested fix works. However, I don't have commit bit for binutils. -- You are receiving this mail because: You are on the CC list f

[Bug ld/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation

2016-08-17 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20475 --- Comment #4 from whitequark at whitequark dot org --- Created attachment 9442 --> https://sourceware.org/bugzilla/attachment.cgi?id=9442&action=edit OR1K target patch -- You are receiving this mail because: You are on the CC l

[Bug ld/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation

2016-08-17 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20475 --- Comment #3 from whitequark at whitequark dot org --- Actually, I might be wrong about this, since the comment in elflink.c implies that the behavior is intentional. I'll attach another patch, which fixes the logic of reloc

[Bug ld/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation

2016-08-16 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20475 --- Comment #1 from whitequark at whitequark dot org --- The previous comment is not quite right. 1) The _GLOBAL_OFFSET_TABLE_ did not point at the end of .got.plt but at the start. 2) This is a bug in the architecture-independent ELF backend

[Bug ld/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation

2016-08-16 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20475 --- Comment #2 from whitequark at whitequark dot org --- Created attachment 9439 --> https://sourceware.org/bugzilla/attachment.cgi?id=9439&action=edit Patch -- You are receiving this mail because: You are on the CC list for

[Bug ld/20475] New: Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation

2016-08-16 Thread whitequark at whitequark dot org
Version: 2.25 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: whitequark at whitequark dot org Target Milestone: --- I am using ld 2.25.1 built for or1k-elf target

[Bug binutils/18759] R_OR1K_*_PCREL should have pcrel_offset=TRUE

2015-09-25 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=18759 --- Comment #20 from whitequark at whitequark dot org --- Thanks! -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org

[Bug binutils/18759] R_OR1K_*_PCREL should have pcrel_offset=TRUE

2015-09-25 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=18759 --- Comment #17 from whitequark at whitequark dot org --- I use --target=or1k-linux, since I need to generate shared object files. I still run them on bare metal but it looks like -linux is the closest I have. -- You are receiving this mail

[Bug binutils/18759] R_OR1K_*_PCREL should have pcrel_offset=TRUE

2015-09-25 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=18759 --- Comment #15 from whitequark at whitequark dot org --- Ah right, sorry. I messed up the git invocation somehow, it seems. -- You are receiving this mail because: You are on the CC list for the bug

[Bug binutils/18759] R_OR1K_*_PCREL should have pcrel_offset=TRUE

2015-09-25 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=18759 --- Comment #13 from whitequark at whitequark dot org --- Nick, that can't be right. I've just looked at binutils gitweb (e.g. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf3

[Bug binutils/18759] R_OR1K_*_PCREL should have pcrel_offset=TRUE

2015-09-21 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=18759 whitequark at whitequark dot org changed: What|Removed |Added Attachment #8474|0 |1 is

[Bug binutils/18759] R_OR1K_*_PCREL should have pcrel_offset=TRUE

2015-09-21 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=18759 --- Comment #10 from whitequark at whitequark dot org --- Ok, I took a shot at fixing gas today. To recap... Here is the minimal testcase: .section .data1 .long 0 x: .long 0 .section .data2 .long 0 .long 0 y: .long (x

[Bug binutils/18759] R_OR1K_*_PCREL should have pcrel_offset=TRUE

2015-08-30 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=18759 --- Comment #9 from whitequark at whitequark dot org --- I have confirmed that, at least, gas emits PC-relative relocations incorrectly. I will fix that. Speaking of the ABI: OR1K does not have a document (any document) which specifies the

[Bug binutils/18759] R_OR1K_*_PCREL should have pcrel_offset=TRUE

2015-08-13 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=18759 --- Comment #7 from whitequark at whitequark dot org --- Why did you revert this? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug

[Bug binutils/18759] R_OR1K_*_PCREL should have pcrel_offset=TRUE

2015-08-13 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=18759 --- Comment #5 from whitequark at whitequark dot org --- I have looked at this and it is not a bug I've introduced. The test xfails or32, which is how or1k used to be named. The test was not updated, which has in fact hidden this very bug

[Bug binutils/18759] R_OR1K_*_PCREL should have pcrel_offset=TRUE

2015-08-12 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=18759 --- Comment #4 from whitequark at whitequark dot org --- I will take a look at this soon. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list

[Bug binutils/18759] R_OR1K_*_PCREL should have pcrel_offset=TRUE

2015-08-02 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=18759 whitequark at whitequark dot org changed: What|Removed |Added CC||whitequark at

[Bug binutils/18759] New: R_OR1K_*_PCREL should have pcrel_offset=TRUE

2015-08-02 Thread whitequark at whitequark dot org
: binutils Assignee: unassigned at sourceware dot org Reporter: whitequark at whitequark dot org Target Milestone: --- Created attachment 8474 --> https://sourceware.org/bugzilla/attachment.cgi?id=8474&action=edit Patch Currently, the OpenRISC1000 relocations R_OR1K_{