testcase to reproduce the problem that
would really help.
In the worst case, I could attach my .o files, the linker script and
the linker
command line. I will try to see if I can limit the test case to only one .o.
Thanks,
Jakub
section (line is not present).
We use binutils 2.16 cross compiled for IA-32.
Is there anything wrong with our linking process or is it a bug in ld?
Please, Cc: me as I don't read this mailing list.
Thanks for your help,
Jakub
OUTPUT_FORMAT(binary)
ENTRY(kernel_image_start)
SEC
this mailing list.
Thanks for your help,
Jakub
OUTPUT_FORMAT(binary)
ENTRY(kernel_image_start)
SECTIONS {
.unmapped 0x8000: AT (0x8000) {
unmapped_ktext_start = .;
*(K_TEXT_START);
*(K_TEXT_START_2);
unmapped_ktext_end = .;
unmapped_kdata_start = .;
*(K_DATA_START);
LONG(0xdea
st regards,
Jakub
MIPS_BINUTILS_DIR=/usr/local/mipsel/bin
MIPS_TARGET=mipsel-linux-gnu
CC=$(MIPS_BINUTILS_DIR)/$(MIPS_TARGET)-gcc
LD=$(MIPS_BINUTILS_DIR)/$(MIPS_TARGET)-ld
ASFLAGS=-mips2
LFLAGS=-e start -T _link.ld
.S.o:
$(CC) $(ASFLAGS) -c -o $@ $<
.c.o:
$(CC) -msof
/DISCARD/ : {
*(*);
}
}
I would be grateful for any hint that would explain the sudden runaway
gp offset.
Regards,
Jakub
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: jakub at redhat dot com
CC: bug-binutils at gnu dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=2721
-
--- Additional Comments From jakub at redhat dot com 2006-06-01 13:40
---
Oops, actually, swap the order of libfoo.so and libbar.so on the last command
line and then it is a regression from older binutils (e.g. 2.16.91.0.6
20060212).
echo 'int foo1;' | gcc -shared -fpic -
--- Additional Comments From jakub at redhat dot com 2006-06-01 15:34
---
http://sources.redhat.com/ml/binutils/2006-06/msg9.html
--
http://sourceware.org/bugzilla/show_bug.cgi?id=2721
--- You are receiving this mail because: ---
You are on the CC list for the bug, or
nt: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: jakub at redhat dot com
CC: bug-binutils at gnu dot org
GCC target triplet: ia64-linux
http://sourceware.org/bugzilla/show_bug.cgi?id=4409
--- You are receiving this mail because: ---
Y
--- Additional Comments From jakub at redhat dot com 2007-07-23 13:39
---
If you get an 8 byte .eh_frame_hdr section in the linked libc.so, then
I'd like an reproducer from you, because all my x86_64 glibcs are just fine
when compiled with recent (e.g. 2.17.50.0.12) binutils
--- Additional Comments From jakub at redhat dot com 2007-07-31 08:37
---
I don't see anything wrong on the generated .eh_frame, it is properly
terminated,
seems to cover everything it should and .eh_frame_hdr looks sane as well.
So this definitely doesn't look like a binu
--- Additional Comments From jakub at redhat dot com 2007-08-06 18:59
---
I have posted an unwinder patch in the thread I referenced, see
http://gcc.gnu.org/ml/gcc/2006-12/msg00312.html
but that was without ChangeLog entry, I got no feedback and forgot about it
(because in the meantime
--- Additional Comments From jakub at redhat dot com 2007-08-16 08:46
---
Why should it? It contains only precomputed redundant info which you can find
out from readelf -S (i.e. where .eh_frame section is located) and readelf -wf.
--
What|Removed
--- Additional Comments From jakub at redhat dot com 2007-08-16 08:47
---
Which compilers violate the TLS ABI? tls.pdf clearly says that the sequences
are not optional, if you use the corresponding relocations, you must use them
only in the listed sequences.
--
What
--- Additional Comments From jakub at redhat dot com 2008-03-25 15:06
---
Do we need to do this even when info->relocatable? PGI apparently uses
(or used?) global symbols in .debug_info sections and referenced them from
within object's .debug_info section. With this change,
link
time.
--
Summary: -pie issues with TLS relocations
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy:
--- Additional Comments From jakub at redhat dot com 2008-04-22 09:23
---
Created an attachment (id=2715)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=2715&action=view)
bz6443.patch
Attached is just very lightly tested x86_64 set of changes, but i386, ppc,
ppc64 an
--
What|Removed |Added
CC||drepper at redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=6443
--- You are receiving this
--- Additional Comments From jakub at redhat dot com 2008-04-24 13:11
---
The important thing is that executables and PIEs are always the first in the
symbol search scope, so the linker can compute the offsets within the TLS block
at runtime. For shared libraries you can't do tha
--- Additional Comments From jakub at redhat dot com 2008-04-24 13:46
---
That's certainly not enough, see the testcase I've provided. There are various
relocations:
0003 000b0016 R_X86_64_GOTTPOFF 0008 c +
fffc
00
http://sourceware.org/bugzilla/show_bug.cgi?id=13817
Bug #: 13817
Summary: Broken IFUNC support
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo:
http://sourceware.org/bugzilla/show_bug.cgi?id=13817
--- Comment #1 from Jakub Jelinek 2012-03-07 10:24:56
UTC ---
Created attachment 6264
--> http://sourceware.org/bugzilla/attachment.cgi?id=6264
ifunctest.tar.bz2
CC='gcc -m32' sh ./ifunc.sh
LD_LIBRARY_PATH=. ./ifunc3
shows
http://sourceware.org/bugzilla/show_bug.cgi?id=13817
--- Comment #3 from Jakub Jelinek 2012-03-08 08:09:51
UTC ---
I think you can keep x86_64 as is. For i386 such PLT slots in the non-pic
binaries could stay, but if we don't have any registers that we can clobber,
the special alternat
http://sourceware.org/bugzilla/show_bug.cgi?id=14309
Bug #: 14309
Summary: gold doesn't build with gcc 4.1.3
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: gold
http://sourceware.org/bugzilla/show_bug.cgi?id=14309
--- Comment #2 from Jakub Jelinek 2012-07-02 05:52:18
UTC ---
That is not a documented minimum is still that 4.1.3 and until gdb_index.cc
stuff has been added it worked just fine. GCC 4.1.x is still widely deployed
as a system compiler, and
http://sourceware.org/bugzilla/show_bug.cgi?id=14309
--- Comment #6 from Jakub Jelinek 2012-07-03 06:39:19
UTC ---
The relevant upstream libstdc++-v3 change seems to be
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118991
I guess alternatively gold could (with the same configure che
http://sourceware.org/bugzilla/show_bug.cgi?id=14309
--- Comment #11 from Jakub Jelinek 2012-07-11
11:54:33 UTC ---
(In reply to comment #10)
> The gold README says that GCC 4.1.2 is known to fail and GCC 4.1.3 is known to
> work. I think it's useful to ensure that gold compile with
http://sourceware.org/bugzilla/show_bug.cgi?id=6443
Jakub Jelinek changed:
What|Removed |Added
Blocks||14940
--
Configure bugmail: http
http://sourceware.org/bugzilla/show_bug.cgi?id=14940
Bug #: 14940
Summary: -pie issues with TLS relocations
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
http://sourceware.org/bugzilla/show_bug.cgi?id=14940
Jakub Jelinek changed:
What|Removed |Added
Target||s390*-*-*
Summary|-pie
http://sourceware.org/bugzilla/show_bug.cgi?id=15149
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at redhat dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=29973
Jakub Jelinek changed:
What|Removed |Added
CC|jakub at redhat dot com|
--
You are receiving this
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: jakub at redhat dot com
Target Milestone: ---
Consider
unsigned foo (void) { return 0xdeadbeefU; }
unsigned long long bar (void) { return 0xdeadbeefcafebabeULL; }
static int p
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: jakub at redhat dot com
Target Milestone: ---
GCC right now when it emits binary data into assembler, whether it is for LTO
sections with -flto or large variable initializers, uses
https://sourceware.org/bugzilla/show_bug.cgi?id=31964
--- Comment #1 from Jakub Jelinek ---
base64 encoding is 4 characters per 3 bytes.
Guess the directive shouldn't be supported for targets which don't have 8-bit
bytes (if there are any).
--
You are receiving this mail because:
https://sourceware.org/bugzilla/show_bug.cgi?id=31964
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=31964
--- Comment #3 from Jakub Jelinek ---
(In reply to Nick Clifton from comment #2)
> Hi Jakub,
>
> Does libiberty (or some other library) have a base64 decoding function ?
I don't think so.
> If not, I guess I will have
https://sourceware.org/bugzilla/show_bug.cgi?id=31964
--- Comment #5 from Jakub Jelinek ---
Comment on attachment 15612
--> https://sourceware.org/bugzilla/attachment.cgi?id=15612
Proposed patch
Thanks, will try tomorrow.
Just some nits:
1) @command{uuencode} program's @code{-m} opt
https://sourceware.org/bugzilla/show_bug.cgi?id=31964
--- Comment #7 from Jakub Jelinek ---
So, I've tried your patch on my short #embed testcase:
unsigned char a[] = {
#embed "cc1plus"
};
with the #embed patchset for GCC, where cc1plus is 273372376 bytes long binary.
Assembly fo
: ld
Assignee: unassigned at sourceware dot org
Reporter: jakub at redhat dot com
Target Milestone: ---
As I've already mentioned in
https://bugzilla.redhat.com/show_bug.cgi?id=1623218#c13
I think it is complete waste to generate 4 PT_LOAD segments for -z
separate-code,
IMN
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: jakub at redhat dot com
Target Milestone: ---
As mentioned in http://gcc.gnu.org/PR90028 while a gas bug has been fixed since
2.31, I couldn't find an
https://sourceware.org/bugzilla/show_bug.cgi?id=24434
--- Comment #4 from Jakub Jelinek ---
Well, ideally not just that, but much more.
grep 'gather.*(,' gas/testsuite/gas/i386/*.s
shows those VEX encoded ones testing this (in AT&T mode), so perhaps just copy
and tweak all or b
https://sourceware.org/bugzilla/show_bug.cgi?id=24434
--- Comment #6 from Jakub Jelinek ---
It is not a dup, this PR is about missing testsuite coverage, which is still
the case on binutils trunk.
--
You are receiving this mail because:
You are on the CC list for the bug
https://sourceware.org/bugzilla/show_bug.cgi?id=24434
--- Comment #9 from Jakub Jelinek ---
Yes, but none of those tests test the VSIB addressing.
We do have AVX2 tests for no base register, why not have also AVX512 VSIB
tests?
--
You are receiving this mail because:
You are on the CC list for
https://sourceware.org/bugzilla/show_bug.cgi?id=26312
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at redhat dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=26312
--- Comment #4 from Jakub Jelinek ---
The gABI says:
sh_entsize
Some sections hold a table of fixed-size entries, such as a symbol table.
For such a section, this member gives the size in bytes of each entry. The
member contains 0 if the
Assignee: unassigned at sourceware dot org
Reporter: jakub at redhat dot com
Target Milestone: ---
#include
int foo (int x) { if (__builtin_constant_p (x)) return getpid (); return 0; }
compiled with
gcc -shared -fpic -O2 -flto -o testpid.so testpid.c
nm testpid.so | grep getpid; nm -D
https://sourceware.org/bugzilla/show_bug.cgi?id=26806
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: jakub at redhat dot com
Target Milestone: ---
Kernel built by gcc 11 latest snapshots configured against latest binutils
fails to link:
ld: .init.data has both
https://sourceware.org/bugzilla/show_bug.cgi?id=27098
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--
You
https://sourceware.org/bugzilla/show_bug.cgi?id=27231
--- Comment #9 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #6)
> GCC 11 also generates:
>
> 0176 2097 (base address)
> 017f 2097 20f8
> 0182 0
https://sourceware.org/bugzilla/show_bug.cgi?id=27215
--- Comment #5 from Jakub Jelinek ---
Any reason why at least for now you can't add partial .{s,u}leb128 support?
I.e. support non-constant .{s,u}leb128 in .debug* sections as long as it refers
to .debug* section labels and not to
y: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: jakub at redhat dot com
Target Milestone: ---
In https://bugzilla.redhat.com/show_bug.cgi?id=2052228 ld reports weird
/usr/bin/ld: /usr/bin/ld: DWARF error: could not find abbrev number 62
diagnostics. The o
--- Additional Comments From jakub at redhat dot com 2009-06-09 11:43
---
Created an attachment (id=3988)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=3988&action=view)
z2.s.bz2
This looks like a gas bug to me. At least from brief look at .cfi_* directives
in the a
--- Additional Comments From jakub at redhat dot com 2009-06-09 11:48
---
Small testcase:
.text
.cfi_startproc
.skip 16
.cfi_def_cfa 0, 16
.skip 75031
.cfi_def_cfa 0, 64
.cfi_endproc
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10255
--- You are receiving this mail
--
What|Removed |Added
AssignedTo|unassigned at sources dot |jakub at redhat dot com
|redhat dot com |
Status|NEW
FUNC gas problem
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: gas
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: jakub at redhat dot com
CC:
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: jakub at redhat dot com
CC: bug-binutils at gnu dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=10270
--- Yo
--- Additional Comments From jakub at redhat dot com 2009-06-12 19:10
---
The problem with using normal symbol is that if some shared library calls such a
symbol, the .got.plt slot in the shared library will contain address of the .plt
slot in the binary and only its .got.plt will
--
What|Removed |Added
CC||drepper at redhat dot com,
||roland at redhat dot com
http://so
Component: binutils
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: jakub at redhat dot com
CC: bug-binutils at gnu dot org
GCC target triplet: x86_64-linux
http://sourceware.org/bugzilla/show_bug.cgi?id=10337
--- You are receiving
--
What|Removed |Added
CC||hjl dot tools at gmail dot
||com
http://sourceware.org/bugzilla
GLOBAL DEFAULT UND library_func2
with CVS trunk.
--
Summary: ld incorrectly creates STT_GNU_IFUNC SHN_UNDEF symbols
Product: binutils
Version: 2.20 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
As
--- Additional Comments From jakub at redhat dot com 2009-07-21 21:15
---
Works for me.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10426
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is
: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: jakub at redhat dot com
CC: bug-binutils at gnu dot org,hjl dot tools at gmail dot
com
GCC target
--- Additional Comments From jakub at redhat dot com 2009-07-22 20:11
---
Ah, attachment too large.
Use http://sunsite.mff.cuni.cz/private/ldconfig.tar.bz2
instead.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10433
--- You are receiving this mail because: ---
You are
--- Additional Comments From jakub at redhat dot com 2009-07-22 20:52
---
When linked with 2.19.51.0.11 (which works), .rela.plt contains:
Relocation section '.rela.plt' at offset 0x1a0 contains 8 entries:
Offset Info Type Symb
x27;ed in between.
--
Summary: strip -g breaks objects with STB_GNU_UNIQUE
Product: binutils
Version: 2.20 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: binutils
AssignedTo: unassigned at sources dot redhat dot
--- Additional Comments From jakub at redhat dot com 2009-08-06 12:29
---
With s/gnu_object_// it works, the difference in readelf -Wa between y.o and z.o
is just the order of local symbols in .symtab.
But with STB_GNU_UNIQUE, the _ZN1AIiE1aE symbol (UNIQUE) is also reordered,
between
--- Additional Comments From jakub at redhat dot com 2009-08-06 12:45
---
Created an attachment (id=4114)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=4114&action=view)
binutils-bz10492.patch
Indeed, you're right. Following patch cures it.
--
http://so
n: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: jakub at redhat dot com
CC: bug-binutils at gnu dot org
GCC target triplet: x86_64-linux
http://sourcew
--
What|Removed |Added
CC||hjl dot tools at gmail dot
||com
http://sourceware.org/bugzilla
ssigned at sources dot redhat dot com
ReportedBy: jakub at redhat dot com
CC: amodra at bigpond dot net dot au,bug-binutils at gnu dot
org
GCC target triplet: powerpc64-linux
http://sourceware.org/bugzilla/show_bug.cgi?id=11012
--- You are receiving
t sources dot redhat dot com
ReportedBy: jakub at redhat dot com
CC: bug-binutils at gnu dot org,hjl dot tools at gmail dot
com
http://sourceware.org/bugzilla/show_bug.cgi?id=11434
--- You are receiving this mail because: ---
You are on the CC lis
http://sourceware.org/bugzilla/show_bug.cgi?id=12451
Summary: --build-id regression
Product: binutils
Version: 2.22 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: binutils
AssignedTo: unassig...@sources.
http://sourceware.org/bugzilla/show_bug.cgi?id=12451
Jakub Jelinek changed:
What|Removed |Added
CC||nickc at redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=12451
--- Comment #1 from Jakub Jelinek 2011-01-28 14:33:48
UTC ---
Actually, it seems upstream binutils probably never handled it right and it
seems Fedora had some local patch for it that got dropped as redundant when it
actually has never been
http://sourceware.org/bugzilla/show_bug.cgi?id=12451
Jakub Jelinek changed:
What|Removed |Added
Component|binutils|ld
--
Configure bugmail: http
http://sourceware.org/bugzilla/show_bug.cgi?id=12669
Summary: Suspected bug in calculation of gp-relative offsets
for ia64 target
Product: binutils
Version: 2.21
Status: NEW
Severity: normal
Priority: P2
http://sourceware.org/bugzilla/show_bug.cgi?id=12669
--- Comment #1 from Jakub Jermar 2011-04-13 13:22:46
UTC ---
Created attachment 5669
--> http://sourceware.org/bugzilla/attachment.cgi?id=5669
HelenOS testcase showing ld 2.21 computes apparently wrong gp-relative offsets
--
Config
http://sourceware.org/bugzilla/show_bug.cgi?id=12669
--- Comment #3 from Jakub Jermar 2011-04-13 14:16:02
UTC ---
(In reply to comment #2)
> Note that the linker does not always put gp at the start of the .got section.
> If you want to force a particular gp value you need to define the
http://sourceware.org/bugzilla/show_bug.cgi?id=12727
Summary: ld ppc64 bug with dot symbols
Product: binutils
Version: 2.22 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassig...@source
http://sourceware.org/bugzilla/show_bug.cgi?id=12727
Jakub Jelinek changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment
http://sourceware.org/bugzilla/show_bug.cgi?id=12921
Summary: sh_offset for SHT_NOBITS sections
Product: binutils
Version: 2.22 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassig...@so
http://sourceware.org/bugzilla/show_bug.cgi?id=12921
--- Comment #3 from Jakub Jelinek 2011-06-23 07:32:34
UTC ---
The intention of prelink --undo is that it reverts the binary/shared library to
the original, bitwise, content. During prelinking the binary/shared library
usually grows, and on
http://sourceware.org/bugzilla/show_bug.cgi?id=12921
--- Comment #5 from Jakub Jelinek 2011-06-23 13:55:28
UTC ---
Sure, at least it got caught by prelink testsuite.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because
86 matches
Mail list logo
