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 for this from the g
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} option
I t
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 to steal^H^H^H^H b
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 #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:
You are on the
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
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
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
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
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 code section
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 213d 00
https://sourceware.org/bugzilla/show_bug.cgi?id=27098
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--
You ar
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=26806
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
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=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 s
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=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=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 #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 big part of the
grep
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
: 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
http://sourceware.org/bugzilla/show_bug.cgi?id=15149
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at redhat dot com
--- Comment
http://sourceware.org/bugzilla/show_bug.cgi?id=14940
Jakub Jelinek changed:
What|Removed |Added
Target||s390*-*-*
Summary|-pie issu
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=6443
Jakub Jelinek changed:
What|Removed |Added
Blocks||14940
--
Configure bugmail: http://sou
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 4.1.x, but
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 check) just c
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 h
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=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 alternate plt slo
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 the segfault (the
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=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: --
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 un
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=12727
Jakub Jelinek changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #1
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=12451
Jakub Jelinek changed:
What|Removed |Added
Component|binutils|ld
--
Configure bugmail: http://sourc
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 re
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
Summary: --build-id regression
Product: binutils
Version: 2.22 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: binutils
AssignedTo: unassig...@sources.
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
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
--
What|Removed |Added
CC||hjl dot tools at gmail dot
||com
http://sourceware.org/bugzilla
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
--- 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
--- 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
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-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
--- 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
: 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-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
signedTo: 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
http://sourceware.org/bugzilla/show_bug.cgi?id=10426
--- You are receiving this mail beca
--
What|Removed |Added
CC||hjl dot tools at gmail dot
||com
http://sourceware.org/bugzilla
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||drepper at redhat dot com,
||roland at redhat dot com
http://so
--- 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
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
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:
--
What|Removed |Added
AssignedTo|unassigned at sources dot |jakub at redhat dot com
|redhat dot com |
Status|NEW
--- 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
--- 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 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
--- 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
--
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-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
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-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,
--- 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 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-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-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-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
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 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
--- 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 -
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
-
78 matches
Mail list logo
