http://sourceware.org/bugzilla/show_bug.cgi?id=15435
--- Comment #2 from Rafael Ávila de Espíndola 2013-05-06 19:09:08 UTC ---
Created attachment 7016
--> http://sourceware.org/bugzilla/attachment.cgi?id=7016
Assembly testcase
This reproduces with
$ gcc test.s -o test.so -shared
Whe
gmail
||dot com
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils
at gmail
dot com
--
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
Severity: enhancement
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: rafael.espindola at gmail dot com
On ELF one can easily create two sections with the same name in different
comdats
at gmail
dot com
--
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
https://sourceware.org/bugzilla/show_bug.cgi?id=16753
Rafael Ávila de Espíndola cha
nged:
What|Removed |Added
CC||iains at sourceware
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: rafael.espindola at gmail dot com
When the type of a symbol is changed, it may or may not be propagated symbols
based on it.
Given
.type b, @object
a = b
b:
.type b, @function
The
Component: gold
Assignee: ian at airs dot com
Reporter: rafael.espindola at gmail dot com
CC: ccoutant at google dot com
Created attachment 7501
--> https://sourceware.org/bugzilla/attachment.cgi?id=7501&action=edit
testcase
I was curious if R_X86_64_TPOFF3
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ian at airs dot com
Reporter: rafael.espindola at gmail dot com
CC: ccoutant at google dot com
Created attachment 7516
--> https://sourceware.org/bugzilla
https://sourceware.org/bugzilla/show_bug.cgi?id=16279
Rafael Ávila de Espíndola cha
nged:
What|Removed |Added
CC||ktietz70 at googlem
Priority: P2
Component: gprof
Assignee: unassigned at sourceware dot org
Reporter: rafael.espindola at gmail dot com
Created attachment 7654
--> https://sourceware.org/bugzilla/attachment.cgi?id=7654&action=edit
testcase
The testcase should be fairly self co
https://sourceware.org/bugzilla/show_bug.cgi?id=17081
Rafael Ávila de Espíndola cha
nged:
What|Removed |Added
CC||ccoutant at google
https://sourceware.org/bugzilla/show_bug.cgi?id=17081
--- Comment #3 from Rafael Ávila de Espíndola ---
This reduces to a trivial link time problem:
$ cat start.s
.globl _start
.type _start,#function
_start:
bl __rel_iplt_start
.globl my_memcpy
my_memcpy:
.type my_memcpy, #gnu
Priority: P2
Component: gold
Assignee: ccoutant at google dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
Created attachment 7691
--> https://sourceware.org/bugzilla/attachment.cgi?id=7691&action=edit
t
at gmail
dot com
--
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
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: rafael.espindola at gmail dot com
Created attachment 7770
--> https://sourceware.org/bugzilla/attachment.cgi?id=7770&action=edit
testcase
The attached testcase has a .init_array that is in a comdat.
Wi
https://sourceware.org/bugzilla/show_bug.cgi?id=17350
Rafael Ávila de Espíndola cha
nged:
What|Removed |Added
CC||amodra at gmail dot
https://sourceware.org/bugzilla/show_bug.cgi?id=17350
Rafael Ávila de Espíndola cha
nged:
What|Removed |Added
Status|NEW |RESOLVED
y: P2
Component: gold
Assignee: ccoutant at google dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
I noticed that gold's exception_static_test test was failing on my machine
(fedora 20 x86_64).
The link line is
gcctestdir/ld --build-i
https://sourceware.org/bugzilla/show_bug.cgi?id=17366
Rafael Ávila de Espíndola cha
nged:
What|Removed |Added
CC||jan.kratochvil at r
https://sourceware.org/bugzilla/show_bug.cgi?id=16773
--- Comment #3 from Rafael Ávila de Espíndola ---
(In reply to Cary Coutant from comment #2)
> Fixed on trunk.
>
> How did you generate test.o? Can the compiler generate the relocation
> against the .tdata section symbol, or did you do
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at google dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
Created attachment 7814
--> https://sourceware.org/bugzilla/attachment.cgi?id=7
Component: gold
Assignee: ccoutant at google dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
Linking clang with gold produces a binary with 185552 symbols in .symtab. With
gnu ld, only 60018.
The result is that when using --strip-all
Assignee: ccoutant at google dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
$ echo > t.s
$ gcc -c t.s
$ valgrind --leak-check=full --show-leak-kinds=definite ld-new -shared t.o -o
t.so
==9661== Memcheck, a memory error detector
==9
Priority: P2
Component: gold
Assignee: ccoutant at google dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
$ cat test.s
.section .foo,""
$ cat test2.s
.section.foo,"a"
bar:
$ gcc -c tes
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: rafael.espindola at gmail dot com
$ cat test3.c
void h(void) {
}
$ cat test2.c
void h(void);
void f(void) {
h();
}
$ cat test.c
void f(void);
int main(void) {
f();
}
$ gcc test3.c -fPIC -shared -o test3.so
$ gcc
https://sourceware.org/bugzilla/show_bug.cgi?id=17558
Rafael Ávila de Espíndola cha
nged:
What|Removed |Added
CC||hjl.tools at gmail
gold
Assignee: ccoutant at google dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
Created attachment 8008
--> https://sourceware.org/bugzilla/attachment.cgi?id=8008&action=edit
testcase
With the attached testcase, running
at gmail
dot com
--
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
Component: gold
Assignee: ccoutant at google dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
Created attachment 8090
--> https://sourceware.org/bugzilla/attachment.cgi?id=8090&action=edit
testcase
The attached testcase has a 3
at gmail
dot com
--
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
Assignee|ccoutant at google dot com |rafael.espindola at
gmail dot com
--- Comment #1 from Rafael Ávila de Espíndola ---
I am working on a patch.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug
dot com,
||rafael.espindola at gmail
dot com
--- Comment #2 from Rafael Ávila de Espíndola ---
(In reply to Alan Modra from comment #1)
> No, it should not be removed. See the gABI. "Therefore, such groups must
> be included or o
https://sourceware.org/bugzilla/show_bug.cgi?id=17931
--- Comment #4 from Rafael Ávila de Espíndola ---
(In reply to Alan Modra from comment #3)
> I hear what you're saying, and accept that gc-sections could be made to w
ork
> for the specific case you present here. However, I'm unconvinced
Priority: P2
Component: gold
Assignee: ccoutant at google dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
$ cat t1.s
ld 6,.LC121@toc@l(9)
.section.rodata.str1.8,"aMS",@progbit
https://sourceware.org/bugzilla/show_bug.cgi?id=18085
Rafael Ávila de Espíndola cha
nged:
What|Removed |Added
CC||amodra at gmail dot
at gmail
dot com
--
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
https://sourceware.org/bugzilla/show_bug.cgi?id=18152
--- Comment #3 from Rafael Ávila de Espíndola ---
Created attachment 8201
--> https://sourceware.org/bugzilla/attachment.cgi?id=8201&action=edit
self contained testcase
This crashes:
$ ld-new -shared -o foo.so -plugin ./LLVMgold.so
https://sourceware.org/bugzilla/show_bug.cgi?id=17902
Rafael Ávila de Espíndola cha
nged:
What|Removed |Added
CC||ccoutant at gmail d
https://sourceware.org/bugzilla/show_bug.cgi?id=17902
--- Comment #3 from Rafael Ávila de Espíndola ---
(In reply to Clément Péron from comment #2)
> Hi,
>
> Any Progress ?
>
> I made an ugly path to put each string in an unique section,
> .rodata.str1.__hash__
>
> it's working fin
https://sourceware.org/bugzilla/show_bug.cgi?id=17498
--- Comment #1 from Rafael Ávila de Espíndola ---
Looks like the difference is just the default value of discard_locals.
With a current clang build:
bfd: 63574408 bytes
gold: 68768280 bytes
gold --discard-locals: 63623736 bytes
-
https://sourceware.org/bugzilla/show_bug.cgi?id=18327
--- Comment #2 from Rafael Ávila de Espíndola ---
I have bisected this to 67f95b96b4d5e8e19520d94bebae92db2f67af74
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bu
https://sourceware.org/bugzilla/show_bug.cgi?id=18327
--- Comment #3 from Rafael Ávila de Espíndola ---
A small assembly testcase:
a.s:
-
.cfi_startproc
.cfi_endproc
---
b.s:
--
.cfi_s
https://sourceware.org/bugzilla/show_bug.cgi?id=18327
--- Comment #4 from Rafael Ávila de Espíndola ---
I should have a patch in a minute.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-bi
https://sourceware.org/bugzilla/show_bug.cgi?id=18327
Rafael Ávila de Espíndola changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resoluti
: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com, tmsriram at google dot com
Target Milestone: ---
ICF has the following logic
// With --icf
https://sourceware.org/bugzilla/show_bug.cgi?id=18440
--- Comment #2 from Rafael Ávila de Espíndola ---
> > This unfortunately doesn't work if the compiler avoids producing the long
> > section names (as llvm now can).
>
> Can we use the symbol name directly?
That would be nice. Which is why I
https://sourceware.org/bugzilla/show_bug.cgi?id=17498
--- Comment #3 from Rafael Ávila de Espíndola ---
(In reply to Cary Coutant from comment #2)
> I believe this only matters because clang's integrated assembler doesn't
> discard the ".L" symbols. Ideally, all those symbols can be dropped from
https://sourceware.org/bugzilla/show_bug.cgi?id=17498
Rafael Ávila de Espíndola changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resoluti
https://sourceware.org/bugzilla/show_bug.cgi?id=17498
--- Comment #6 from Rafael Ávila de Espíndola ---
(In reply to Cary Coutant from comment #5)
> Testcase, please.
From the description:
$ cat test.cpp
void g(const char* x);
void f() {
g("aoeuaoeuaoeuao");
}
$ gcc -shared -fPIC test.cpp -o
Assignee: ccoutant at gmail dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
I just installed fedora 22 on a VM and I am getting the following test failures
on
5d7908e0880030628536a0266968a15922574735
https://sourceware.org/bugzilla/show_bug.cgi?id=18521
--- Comment #1 from Rafael Ávila de Espíndola ---
Created attachment 8361
--> https://sourceware.org/bugzilla/attachment.cgi?id=8361&action=edit
A self contained testcase of one of the test failures
--
You are receiving this mail because:
https://sourceware.org/bugzilla/show_bug.cgi?id=15835
Rafael Ávila de Espíndola changed:
What|Removed |Added
CC||rafael.espindola at gmail
https://sourceware.org/bugzilla/show_bug.cgi?id=19031
--- Comment #1 from Rafael Ávila de Espíndola ---
Created attachment 8653
--> https://sourceware.org/bugzilla/attachment.cgi?id=8653&action=edit
patch
--
You are receiving this mail because:
You are on the CC list for the bug.
Assignee: ccoutant at gmail dot com
Reporter: rafael.espindola at gmail dot com
CC: amonakov at gmail dot com, bugdal at aerifal dot cx,
hjl.tools at gmail dot com, ian at airs dot com
Target Milestone: ---
Created attachment 8652
--> ht
https://sourceware.org/bugzilla/show_bug.cgi?id=19031
--- Comment #4 from Rafael Ávila de Espíndola ---
Created attachment 8665
--> https://sourceware.org/bugzilla/attachment.cgi?id=8665&action=edit
x86_64 testcase
--
You are receiving this mail because:
You are on the CC list for the bug.
__
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
Created attachment 8683
--> https://sourceware.org/bugzi
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
Given
.long __start_bar - .
.long __init_array_start - .
.section
https://sourceware.org/bugzilla/show_bug.cgi?id=19140
--- Comment #1 from Rafael Ávila de Espíndola ---
The issue in gold can be avoided by making the declaration hidden:
.section bar, "a"
.hidden __start_bar
.quad __start_bar
Produces a R_X86_64_RELATIVE. Unfortunately
https://sourceware.org/bugzilla/show_bug.cgi?id=19140
--- Comment #5 from Rafael Ávila de Espíndola ---
> > > Produces a R_X86_64_RELATIVE. Unfortunately that doesn't work with bfd.
> >
> > It works in my experiments.
>
> I should qualify that by saying it "works" in the sense that I see an
>
,
||rafael.espindola at gmail dot
com
--- Comment #2 from Rafael Ávila de Espíndola ---
This bug is still present in gold
--
You are receiving this mail because:
You are on the CC list for the bug
https://sourceware.org/bugzilla/show_bug.cgi?id=18695
Rafael Ávila de Espíndola changed:
What|Removed |Added
CC||rafael.espindola at gmail
https://sourceware.org/bugzilla/show_bug.cgi?id=18609
Rafael Ávila de Espíndola changed:
What|Removed |Added
CC||rafael.espindola at gmail
Assignee: unassigned at sourceware dot org
Reporter: rafael.espindola at gmail dot com
Target Milestone: ---
Given
--
bar:
movq%fs:0, %rax
addqfoo@GOTTPOFF(%rip), %rax
retq
.section.tbss,"awT",@
https://sourceware.org/bugzilla/show_bug.cgi?id=19796
--- Comment #2 from Rafael Ávila de Espíndola ---
How does the dynamic handle this?
A R_X86_64_TPOFF64 with no symbol is just the start of the thread block of the
dso it is in?
--
You are receiving this mail because:
You are on the CC list
https://sourceware.org/bugzilla/show_bug.cgi?id=19796
Rafael Ávila de Espíndola changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resoluti
y: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
Given
local:
.global internal
.internal internal
internal:
.global hidden
.h
https://sourceware.org/bugzilla/show_bug.cgi?id=19823
Rafael Ávila de Espíndola changed:
What|Removed |Added
Summary|gold doesn't consider copy |gold produces copy reloc o
https://sourceware.org/bugzilla/show_bug.cgi?id=19823
--- Comment #5 from Rafael Ávila de Espíndola ---
(In reply to H.J. Lu from comment #4)
> (In reply to Cary Coutant from comment #1)
> >
> > Or, perhaps (I need to check...), gold might be incorrectly allowing
> > the COPY relocation to a prot
https://sourceware.org/bugzilla/show_bug.cgi?id=19823
--- Comment #6 from Rafael Ávila de Espíndola ---
> Or, perhaps (I need to check...), gold might be incorrectly allowing
> the COPY relocation to a protected symbol, failing to consider that
> the bindings within the shared object will be stat
https://sourceware.org/bugzilla/show_bug.cgi?id=16794
--- Comment #2 from Rafael Ávila de Espíndola ---
(In reply to Yin Ma from comment #1)
> This patch made all DWARF DW_AT_name generation are wrong for ARM. Please
> take a look again. I would like to know how LLVM need to work with gold
> link
https://sourceware.org/bugzilla/show_bug.cgi?id=21167
Rafael Ávila de Espíndola changed:
What|Removed |Added
CC||rafael.espindola at gmail
: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: rafael.espindola at gmail dot com
Target Milestone: ---
Given
.section.init_array.00999,"aw"
.section.init_array,"aw"
Assignee: ccoutant at gmail dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
Given just
--
.globl _start
_start:
callq foo
.section.text.bar,&quo
https://sourceware.org/bugzilla/show_bug.cgi?id=22267
Rafael Ávila de Espíndola changed:
What|Removed |Added
CC||rafael.espindola at gmail
https://sourceware.org/bugzilla/show_bug.cgi?id=22268
Rafael Ávila de Espíndola changed:
What|Removed |Added
CC||rafael.espindola at gmail
Assignee: unassigned at sourceware dot org
Reporter: rafael.espindola at gmail dot com
Target Milestone: ---
Relocations in non relocatable ELF files use virtual addresses, not section
offsets. Given that, lld currently produces .rela.plt sections with a sh_info
of 0.
When
https://sourceware.org/bugzilla/show_bug.cgi?id=22587
--- Comment #2 from Rafael Ávila de Espíndola ---
I get an error compiling it:
readelf.c:6210:14: error: ‘filedata’ undeclared (first use in this function);
did you mean ‘file_ptr’?
&& (filedata->file
https://sourceware.org/bugzilla/show_bug.cgi?id=22587
--- Comment #5 from Rafael Ávila de Espíndola ---
The patch avoids the warning. With it in place I think you can remove the
special treatment for .rela.dyn too.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=22587
--- Comment #8 from Rafael Ávila de Espíndola ---
Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://list
IRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
The following testcase fails with gold
$ cat test.s
.
https://sourceware.org/bugzilla/show_bug.cgi?id=22791
Rafael Ávila de Espíndola changed:
What|Removed |Added
CC||ccoutant at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=22791
--- Comment #2 from Rafael Ávila de Espíndola ---
Created attachment 10786
--> https://sourceware.org/bugzilla/attachment.cgi?id=10786&action=edit
testcase
--
You are receiving this mail because:
You are on the CC list for the bug.
___
https://sourceware.org/bugzilla/show_bug.cgi?id=22791
--- Comment #3 from Rafael Ávila de Espíndola ---
It seems to work. The attached hello world has
Type: DYN (Shared object file)
6: 11e0 0 FUNCGLOBAL DEFAULT UND puts@GLIBC_2.2.5
and it work
https://sourceware.org/bugzilla/show_bug.cgi?id=22791
--- Comment #5 from Rafael Ávila de Espíndola ---
(In reply to Cary Coutant from comment #4)
> This would be fine if we knew for a fact that the relocation is on a call
> instruction. The problem is that R_X86_64_PC32 isn't always a call
> ins
https://sourceware.org/bugzilla/show_bug.cgi?id=22791
--- Comment #6 from Rafael Ávila de Espíndola ---
Created attachment 10787
--> https://sourceware.org/bugzilla/attachment.cgi?id=10787&action=edit
testcase that prints the address of a function
--
You are receiving this mail because:
You a
https://sourceware.org/bugzilla/show_bug.cgi?id=22791
--- Comment #7 from Rafael Ávila de Espíndola ---
(In reply to Rafael Ávila de Espíndola from comment #5)
> (In reply to Cary Coutant from comment #4)
> > This would be fine if we knew for a fact that the relocation is on a call
> > instructio
https://sourceware.org/bugzilla/show_bug.cgi?id=22791
--- Comment #9 from Rafael Ávila de Espíndola ---
(In reply to Cary Coutant from comment #8)
> (In reply to Rafael Ávila de Espíndola from comment #5)
> > (In reply to Cary Coutant from comment #4)
> > > This would be fine if we knew for a fac
https://sourceware.org/bugzilla/show_bug.cgi?id=22791
--- Comment #11 from Rafael Ávila de Espíndola ---
(In reply to Cary Coutant from comment #10)
> The "official" or "canonical" PLT entry is the one that serves as the
> address of the function throughout the program.
OK, so we were talking ab
https://sourceware.org/bugzilla/show_bug.cgi?id=22791
--- Comment #16 from Rafael Ávila de Espíndola ---
> > If your argument is that you can always treat PC32 relocations on branches
> > as if they were PLT32 relocations, why not just have the compiler emit PLT32
> > relocations in the first pla
https://sourceware.org/bugzilla/show_bug.cgi?id=22791
--- Comment #20 from Rafael Ávila de Espíndola ---
Note that while the assembler change is a nice improvement, the original issue
still exists.
In the testcase that I attached before, the call to foo is now assembled to
R_X86_64_PLT32, but
: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: rafael.espindola at gmail dot com
CC: ccoutant at gmail dot com, hjl.tools at gmail dot com
Target Milestone: ---
Created
https://sourceware.org/bugzilla/show_bug.cgi?id=22791
--- Comment #22 from Rafael Ávila de Espíndola ---
(In reply to H.J. Lu from comment #21)
> (In reply to Rafael Ávila de Espíndola from comment #20)
> > Note that while the assembler change is a nice improvement, the original
> > issue still e
https://sourceware.org/bugzilla/show_bug.cgi?id=22842
--- Comment #2 from Rafael Ávila de Espíndola ---
(In reply to H.J. Lu from comment #1)
> Created attachment 10816 [details]
> A patch
>
> Please try this.
The runtime warning is gone, but I still get two different values for the
address:
$
https://sourceware.org/bugzilla/show_bug.cgi?id=22842
--- Comment #4 from Rafael Ávila de Espíndola ---
(In reply to H.J. Lu from comment #3)
> (In reply to Rafael Ávila de Espíndola from comment #2)
> > (In reply to H.J. Lu from comment #1)
> > > Created attachment 10816 [details]
> > > A patch
https://sourceware.org/bugzilla/show_bug.cgi?id=22842
--- Comment #6 from Rafael Ávila de Espíndola ---
(In reply to H.J. Lu from comment #5)
> (In reply to Rafael Ávila de Espíndola from comment #4)
> > (In reply to H.J. Lu from comment #3)
>
> >
> > Should I close the bug and open a new one f
: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
Created attachment 10817
--> https://sourceware.
https://sourceware.org/bugzilla/show_bug.cgi?id=22844
Rafael Ávila de Espíndola changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=22842
--- Comment #9 from Rafael Ávila de Espíndola ---
(In reply to Cary Coutant from comment #8)
> I still believe that the linker is working as intended. If you want the
> address of the PLT entry, use the PLT32 reloc.
Why should -pie make a dif
http://sourceware.org/bugzilla/show_bug.cgi?id=12049
--- Comment #9 from Rafael Ávila de Espíndola 2010-10-22 18:42:02 UTC ---
The current binutils now gets the two previous tests right (thanks!), but it is
still missing some cases. With the new testcase it encodes a je as
0f 84 02 00 00 00
Tha
1 - 100 of 111 matches
Mail list logo
