[Bug gas/31964] Add directive for more efficient encoding of binary data
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 gcc is 1328371852 bytes long, just
.file "embed-11.c"
.text
.globl a
.data
.align 32
.type a, @object
.size a, 273372376
a:
.byte 127
.string "ELF\002\001\001\003"
.string ""
.string ""
...
.string
"(\035\214\034\347_u\244\rz|~\002\253h\267\271\203v\244\266\372\001\353\363\026\346\365\305\211\005\220\372\215h\267\211{\022\257\277'\0256\215G\2013c.~\244\206\360\2
26|_\226\223\034\177j\232u\300,\003\3273kh\267q\221\302\326\3153\3772\202,\003\327\346\207\3662giJ3\202,\003\327\305\271\234@%v~\2446-\034\257\310\207\302\326=\256h\267\016\237h\267Q
\201\023\257\016\313\302\326q\032\\*\205(u\244\237\023t\244\344Vt\244\247\335\243k\007\256\302\326,th\267}\221h\267\317O\034\257\377\373v\244\227\202a\221$\236\3772\263\326X\221\215M
z\244\216\227\034\257F\213\302\326G\316\302\326\033\277\302\326\177\220h\267\023\263\302\326X\236v\244\034Zt\244\003>\177[\0135\022\257\226ph\267|\377\3033Ox\022\257\214\307\340`\356
\235\3772M>\245\013\321*\003\327=\377\3033"
...
.string ""
.string ""
.byte 0
.ident "GCC: (GNU) 15.0.0 20240703 (experimental)"
.section.note.GNU-stack,"",@progbits
Now, if I hand edit this to replace the first .byte up to the last one
including .string etc. directives in between with
cat cc1plus | base64 | sed 's/^/\t.base64\t"/;s/$/"/'
the new assembly is 422048853 bytes.
time .../gas/as-new -o embed-11.o embed-11.s
real0m10.481s
user0m10.113s
sys 0m0.356s
time .../gas/as-new -o embed-11_.o embed-11_.s
real0m2.519s
user0m2.282s
sys 0m0.233s
md5sum embed-11.o embed-11_.o
049aaf9fdb9cf6f84fd54984ab032ac0 embed-11.o
049aaf9fdb9cf6f84fd54984ab032ac0 embed-11_.o
So, this looks good to me.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/31964] Add directive for more efficient encoding of binary data
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 think base64 program from coreutils is more common than uuencode from
sharutils,
so either mention just that, or both. For no line wrapping base64 has -w 0
option.
2) I don't know how FRAG_APPEND_1_CHAR is expensive compared to say appending
more
characters at a time; if appending more at a time would be cheaper, with
base64
one can cheaply check for the length of the addition (at least number of
non-["=]
characters divided by 4 times 3); but if it is inexpensive, just ignore
Guess the most important thing will be how fast will be the parsing of it (and
encoding on the gcc side). Just running coreutils base64 on 261M file took
around 1s and base64 -d of that too.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/31964] Add directive for more efficient encoding of binary data
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 borrow some code from some > other project. I simply wrote my own, see https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655156.html (the base64_dec_fn helper function, base64_dec array and most of finish_base64_embed). Uses C++ for the base64_dec array initialization, of course it could be initialized on demand at runtime, just wanted to make it more efficient. Now, I don't really remember if gas does any kind of character set translation or not, or whether say 'A' in .ascii/.string etc. routines is expected to be 'A' in gas source and is what is being written to the sections. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31964] Add directive for more efficient encoding of binary data
https://sourceware.org/bugzilla/show_bug.cgi?id=31964 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||nickc at redhat dot com, ||rguenth at gcc dot gnu.org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31964] Add directive for more efficient encoding of binary data
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 CC list for the bug.
[Bug gas/31964] New: Add directive for more efficient encoding of binary data
https://sourceware.org/bugzilla/show_bug.cgi?id=31964 Bug ID: 31964 Summary: Add directive for more efficient encoding of binary data Product: binutils Version: unspecified Status: NEW Severity: normal 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 either the .ascii/.string directives like .string "\304\2347a@\355\004\302tL\302\\\260O>6D\347\266\2527`\200\355\004\276\276L\302j\330'\0279D\347\262\2347`\326v\002_%\354S\017\017\3219i\365\006\214\250\235@\027\324$,\205}\352\271!:G\345\274\331\"l'\020\345f\362U\310>\341\350\020\225+\254\336l\305\265\023\210z1\371\002d\237nz\210\312\3759o\266\216\332\t\321\360\020\225S\253\336d\345\265\023H\202\232|1\261O47D\345\320\2347YN\355\004\220\334L\276\202\330\247\031\035\242ra\325\233\254\236v\002H/&_=\354\323\263\207\250\334\226\363\246\312\327N" .ascii "\0325\371\242a\237\2368D\345\252\325\233*[;\201\242=\223" .string "/\026\366\211\335!*'u\336T\201\332\t\024\351\230|\241\260O\254\r\321\270\303\352\215\025`;\001\234/\223.B\366\251%\207h\\\241\363\306\312\332N" .ascii "\247\304\244\013\217}b\341!\032\347W\275\261\"j'`\0035\351\232" .ascii "c\237Xn\210\306\3619o\244\204\355\004h\334L\272\322\330\247\025" or emits it as a sequence of .byte directives .byte 127 .byte 69 .byte 76 .byte 70 .byte 2 .byte 1 .byte 1 .byte 3 .byte 0 .byte 0 For ASCII or mostly ASCII data .string/.ascii are just fine, with 1 or slightly more than 1 assembly character per data section byte, but as can be seen above, for non-ASCII values that is 4 characters per byte or in the .byte sequence case up to 11 characters for byte. I've been wondering whether gas couldn't add a .base64 directive, base64 encoding/decoding is pretty fast thing and can be implemented in a few lines of C or C++ code efficiently. It is something I'm also proposing for #embed preprocessing. Perhaps .base64 argument could be a string, like: .base64 "RUxGAgEBAwAAAgA+AAEAAABQ00AAAEAA2CBLEAAAQAA4AA4A" .base64 "QAAsACsABgQAAABAAEAAQAAAQABQAwAAABADCAAA" .base64 "AAA=" https://datatracker.ietf.org/doc/html/rfc4648#section-4 I'd probably not add any requirements on the line (string) length, not accept any line breaks nor other characters other than [A-Za-z0-9+/=], just require the string has multiple of 4 characters and so is a valid base64 on its own, with at most = or == at the end, no other = chars. So even .base64 "RUxGAgEBAwAAAgA+AAEAAABQ00AAAEAA2CBLEAAAQAA4AA4AQAAsACsABgQAAABAAEAAQAAAQABQAwAAABADCAA=" etc. would be valid. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31454] New: Add constant tracking to disassembly (objdump -d, gdb disas)
https://sourceware.org/bugzilla/show_bug.cgi?id=31454
Bug ID: 31454
Summary: Add constant tracking to disassembly (objdump -d, gdb
disas)
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
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;
int *baz (void) { return }
int main () {}
When linked on x86_64 with -O2 -fpic, objdump -d and gdb disassemble already
does some
immediate visualization to help user reading the code:
00401140 :
401140: 48 8d 05 d9 2e 00 00lea0x2ed9(%rip),%rax#
404020 <__TMC_END__>
401147: c3 ret
or
Dump of assembler code for function baz:
0x00401140 <+0>: lea0x2ed9(%rip),%rax# 0x404020
0x00401147 <+7>: ret
knows to handle lea with immediate and (%rip) to add the 0x2ed9 in there with
end of the instruction and print the resulting immediate and perhaps symbolic
rendering of it in the comment.
The 0xdeadbeef and 0xdeadbeefcafebabe immediates are clearly shown in the
assembly, so there is no need to help users reading that.
Now, let's try the same on other arches, e.g. aarch64:
400140: 5297dde0mov w0, #0xbeef //
#48879
400144: 72bbd5a0movkw0, #0xdead, lsl #16
in foo,
400160: d29757c0mov x0, #0xbabe //
#47806
400164: f2b95fc0movkx0, #0xcafe, lsl #16
400168: f2d7dde0movkx0, #0xbeef, lsl #32
40016c: f2fbd5a0movkx0, #0xdead, lsl #48
in bar and
400180: f0e0adrpx0, 41f000
400184: 913fa000add x0, x0, #0xfe8
in baz. It would be helpful if the disassembly could for a small set of
instructions which are usually involved in constant creations in GPR registers
be able to propagate constants through them; for each GPR register remember if
it is set to a known constant (then also the constant value) or not. When
seeing a start of a function (new symbol?)
reset this knowledge, maybe also reset it on possible conditional/unconditional
jump destinations from the same function (though computing that might require
another pass through the instructions), when seeing a GPR register set with a
handled instruction to constant remember that constant, when seeing a handled
instruction where all the inputs
have known constant values try to evaluate the instruction and remember the
resulting constant and then show in comments like in the lea case above the
immediate plus symbolic rendering if any. And when seeing an unhandled
instruction that sets or clobbers some GPR (or might do that), forget the value
of that register.
So, for foo above, remember that w0 is set to 0xbeef, interpret the movk
instruction that the result is 0xdeadbeef and tell it to the user, ditto for
the second case, similarly remember for adrp and handle the add too, printing
there 41ffe8 .
Now, repeat this on other arches, powerpc{,64,64le}, sparc{,64}, ...
On s390x, one can also see that it loads some constants from
.rodata/.data.rel.ro* and similar sections, those too would be nice to track
and print.
This would help users so that they don't have to scratch their heads
interpreting the instructions or having to actually see what it does at runtime
to find out what it actually computes.
In gdb, sometimes one just disassembles part of a function, not the whole one,
I think it would be perfectly fine to start with nothing known state at the
start of such a block and print only what is discovered in that block.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/29973] x86_64-w64-mingw32-g++ ld: helloworld.exe:.rdata_r: section below image base for windows
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 mail because: You are on the CC list for the bug.
[Bug ld/28915] New: dwarf2.c doesn't correctly parse DW_UT_skeleton
https://sourceware.org/bugzilla/show_bug.cgi?id=28915
Bug ID: 28915
Summary: dwarf2.c doesn't correctly parse DW_UT_skeleton
Product: binutils
Version: 2.39 (HEAD)
Status: NEW
Severity: normal
Priority: 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 object file in question uses -gsplit-dwarf and
readelf -wi
obj/third_party/swiftshader/src/Reactor/swiftshader_subzero/IceTargetLoweringX8664.o
Contents of the .debug_info section:
Compilation Unit @ offset 0x0:
Length:0x2d (32-bit)
Version: 5
Unit Type: DW_UT_skeleton (4)
Abbrev Offset: 0x0
Pointer Size: 8
DWO ID:0xaff01133f289df3e
<0><14>: Abbrev Number: 1 (DW_TAG_skeleton_unit)
<15> DW_AT_ranges : 0xc
<19> DW_AT_low_pc : 0x0
<21> DW_AT_stmt_list : 0x0
<25> DW_AT_dwo_name: (indirect string, offset: 0x39):
obj/third_party/swiftshader/src/Reactor/swiftshader_subzero/IceTargetLoweringX8664.dwo
<29> DW_AT_comp_dir: (indirect string, offset: 0x0):
/builddir/build/BUILD/chromium-98.0.4758.80/out/Headless
<2d> DW_AT_GNU_pubnames: 1
<2d> DW_AT_addr_base : 0x8
62 is equal to 0x3e, i.e. the first byte of DWO ID.
So, this seems to be a bug in bfd/dwarf2.c (parse_comp_unit) which for
DW_UT_type does:
if (unit_type == DW_UT_type)
{
/* Skip type signature. */
info_ptr += 8;
/* Skip type offset. */
info_ptr += offset_size;
}
but should at least also:
else if (unit_type == DW_UT_skeleton || unit_type == DW_UT_split_compile)
/* Skip DWO ID. */
info_ptr += 8;
at minimum.
Minimal reproducer would be something like:
cat > test.c <<\EOF
int foo (void);
int
main ()
{
return foo ();
}
EOF
gcc -gdwarf-5 -gsplit-dwarf -o test{,.c}
The above will just avoid interpreting bytes in the DWO ID as abbrev number
followed by its attribute values etc., for reallly supporting split DWARF more
work would be needed (actually reading the DWO ID, read DW_AT_dwo_name and
DW_AT_comp_dir in the DW_TAG_skeleton_unit, try to find the dwo file and read
it in addition to the skeleton stuff (some sections remain in the .o file like
.debug_addr, others are in the dwo file and others are in both).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/27215] as: Error: non-constant .uleb128 is not supported on riscv64
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?
I mean, the DWARF producers heavily rely on .debug* sections not being relaxed
in any way by the linker, they can have offsets computed etc. and it isn't a
normal code section.
I bet the relaxation you talk about applies to code sections, doesn't it?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/27231] objdump -S doesn't work on DWARF5 generated by GCC 11
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 213d (start == end) > 0187 233f 2346 > 018c > > .LLRL171: > .byte 0x5 > .quad .LBB2156 > .byte 0x4 > .uleb128 .LBB2156-.LBB2156 > .uleb128 .LBE2156-.LBB2156 > .byte 0x4 > .uleb128 .LBB2157-.LBB2156 > .uleb128 .LBE2157-.LBB2156 > .byte 0x4 > .uleb128 .LBB2158-.LBB2156 > .uleb128 .LBE2158-.LBB2156 > .byte 0 > > This triggers: > > if ((low_pc == 0 && high_pc == 0) || low_pc == high_pc) > return FALSE; > > in read_rnglists(). Is this a GCC 11 bug? No, binutils bug. There is nothing special about 0 low or high pc or low_pc == high_pc in .debug_rnglists. The list termination is rather DW_RLE_end_of_list. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27098] aarch64 kernel fails to link due to the __patchable_function_entries changes
https://sourceware.org/bugzilla/show_bug.cgi?id=27098 Jakub Jelinek changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27098] New: aarch64 kernel fails to link due to the __patchable_function_entries changes
https://sourceware.org/bugzilla/show_bug.cgi?id=27098
Bug ID: 27098
Summary: aarch64 kernel fails to link due to the
__patchable_function_entries changes
Product: binutils
Version: 2.36 (HEAD)
Status: NEW
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 ordered [`__patchable_function_entries' in init/main.o]
and unordered [`.init.data' in ./drivers/firmware/efi/libstub/vsprintf.stub.o]
sections
ld: final link failed: bad value
The problem is that gcc now uses SHF_LINK_ORDER for
__patchable_function_entries
sections, and the kernel linker script has:
.init.data : {
KEEP(*(SORT(___kentry+*))) *(.init.data init.data.*) . = ALIGN(8);
__start_mcount_loc = .; KEEP(*(__mcount_loc))
KEEP(*(__patchable_function_entries)) __stop_mcount_loc = .; ... }
Seems the linker refuses to put those SHF_LINK_ORDER input sections into the
same output section with non-SHF_LINK_ORDER sections.
I can understand this being a fatal error for relocatable links, but does
SHF_LINK_ORDER matter after final link of executable or shared library?
I mean, can't we just make the resulting section non-SHF_LINK_ORDER rather than
error?
Or is this a kernel bug?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/26806] Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806 Jakub Jelinek changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||hubicka at gcc dot gnu.org, ||nickc at sourceware dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26806] New: Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806
Bug ID: 26806
Summary: Suspected linker bug with LTO
Product: binutils
Version: 2.35
Status: NEW
Severity: normal
Priority: P2
Component: ld
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 testpid.so | grep getpid
shows getpid@@GLIBC_2.2.5 in both symbol tables when linked with binutils 2.35
and none when linked with binutils 2.31.1.
As the ltrans assembly file lto1 emits doesn't contain any references to
getpid,
i.e. getpid as undefined symbol is there before IPA optimizations and later
optimized away, it doesn't seem like a GCC bug (unless it is a linker plugin
bug, but then, the same linker plugin works fine against older linker).
https://bugzilla.redhat.com/show_bug.cgi?id=1889763
contains another testcase (even more important one, where because of this the
link is rejected, as the symbol kept in symbol table that really shouldn't be
there gets an linker error (__open*_missing_mode).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/26312] ld produces broken PLT on aarch64 with BTI+PAC
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 section does not hold a table of fixed-size entries. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26312] ld produces broken PLT on aarch64 with BTI+PAC
https://sourceware.org/bugzilla/show_bug.cgi?id=26312 Jakub Jelinek changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #1 from Jakub Jelinek --- Non-uniform .plt sizes aren't necessarily a problem, but in that case sh_entsize needs to be changed, either to 0, 1, 4 or perhaps 8, but from the description 0 is probably the best choice. E.g. powerpc 32-bit is using sh_entsize of 0 for .plt too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/24434] Missing testsuite coverage for AVX512F gathers (and scatters?) with no base register
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 the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/24434] Missing testsuite coverage for AVX512F gathers (and scatters?) with no base register
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. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/24434] Missing testsuite coverage for AVX512F gathers (and scatters?) with no base register
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 mode), so perhaps just copy
and tweak all or big part of the
grep '\(gather\|scatter\).*(.*{' gas/testsuite/gas/i386/*.s
tests and remove the base register in those (ditto for Intel mode).
(, has EVEX coverage only in the invalid tests, not the valid ones.
--
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 gas/24434] New: Missing testsuite coverage for AVX512F gathers (and scatters?) with no base register
https://sourceware.org/bugzilla/show_bug.cgi?id=24434 Bug ID: 24434 Summary: Missing testsuite coverage for AVX512F gathers (and scatters?) with no base register Product: binutils Version: 2.33 (HEAD) Status: NEW 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 any gas/testsuite/i386/ testsuite coverage for (,%[xyz]mm*,*) or disp(,%[xyz]mm*,*) VSIB addressing even on binutils trunk. -- 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/23704] New: Too many PT_LOAD segments with -z separate-code
https://sourceware.org/bugzilla/show_bug.cgi?id=23704 Bug ID: 23704 Summary: Too many PT_LOAD segments with -z separate-code Product: binutils Version: 2.31 Status: NEW Severity: normal Priority: P2 Component: 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, IMNSHO 3 PT_LOADs should be enough, which should be achievable by moving for -z separate-code in the linker script all sections that need read-only non-executable before all read-only/executable sections. That way we'd have one PF_R PT_LOAD, then one PF_R|PF_X and one PF_R|PF_W, the last one as before would start with relro sections if -z relro, rather than the current PF_R PT_LOAD, followed by PF_R|PF_X, followed by another PF_R one and finally PF_R|PF_W. -- 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/15149] Weak reference leads to DT_NEEDED entry
http://sourceware.org/bugzilla/show_bug.cgi?id=15149 Jakub Jelinek jakub at redhat dot com changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #4 from Jakub Jelinek jakub at redhat dot com 2013-03-11 17:44:08 UTC --- This change is bogus, and breaks lots of packages. There is nothing wrong with undef weak references that might sometimes be satisfied by some library, but in the next version of the library no longer brought in. DT_NEEDED for undef weak references shouldn't be added, and nothing should be diagnosed. Please revert. -- 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 mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6443] -pie issues with TLS relocations
http://sourceware.org/bugzilla/show_bug.cgi?id=6443 Jakub Jelinek jakub at redhat dot com changed: What|Removed |Added Blocks||14940 -- 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 mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/14940] New: -pie issues with TLS relocations
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
AssignedTo: unassig...@sourceware.org
ReportedBy: ja...@redhat.com
CC: bug-binutils@gnu.org, drepper@gmail.com,
hjl.to...@gmail.com
Depends on: 6443
Classification: Unclassified
+++ This bug was initially created as a clone of Bug #6443 +++
__thread int a;
__thread int b __attribute((tls_model (local-exec)));
__thread int c __attribute((tls_model (initial-exec)));
__thread int d __attribute((tls_model (local-dynamic)));
__thread int e __attribute((tls_model (global-dynamic)));
int
main (void)
{
return a + b + c + d + e;
}
compiled/linked with -O2 -pie -fpie on various arches either doesn't link at
all,
or makes completely unnecessarily a DT_TEXTREL PIE. Tried x86_64, i386, ppc,
ppc64. For the TLS transitions and relocations, PIEs should be handled like
other executables, so many info-shared checks need to be replaced with
!info-executable. For the TLS relocations, even when the executable is
position independent, the offsets within the PIE's TLS block are known at link
time and so relocations like R_X86_64_TPOFF32 can be relocated fully at link
time.
While this is now fixed on i?86/x86_64 and perhaps ppc/ppc64, it isn't fixed on
s390/s390x. See https://bugzilla.redhat.com/show_bug.cgi?id=872148
--
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 mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/14940] s390 -pie issues with TLS relocations
http://sourceware.org/bugzilla/show_bug.cgi?id=14940 Jakub Jelinek jakub at redhat dot com changed: What|Removed |Added Target||s390*-*-* Summary|-pie issues with TLS|s390 -pie issues with TLS |relocations |relocations -- 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 mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/14309] gold doesn't build with gcc 4.1.3
http://sourceware.org/bugzilla/show_bug.cgi?id=14309 --- Comment #11 from Jakub Jelinek jakub at redhat dot com 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 given that 4.1.3 works I don't think it's useful to work around compiler bugs in 4.1.2. GCC 4.1.2-RH is based on FSF GCC 4.1.3 prerelease (note, GCC 4.1.3 has actually never been released). That said, we built internally gold just fine using that compiler with Dodji's patch, perhaps we are using different options. -- 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 mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/14309] gold doesn't build with gcc 4.1.3
http://sourceware.org/bugzilla/show_bug.cgi?id=14309 --- Comment #6 from Jakub Jelinek jakub at redhat dot com 2012-07-03 06:39:19 UTC --- The relevant upstream libstdc++-v3 change seems to be http://gcc.gnu.org/viewcvs?root=gccview=revrev=118991 I guess alternatively gold could (with the same configure check) just cast the long long vals to long or unsigned long before hashing, after all, that is exactly what libstdc++ does with it. -- 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 mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/14309] gold doesn't build with gcc 4.1.3
http://sourceware.org/bugzilla/show_bug.cgi?id=14309 --- Comment #2 from Jakub Jelinek jakub at redhat dot com 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 having very high GCC requirements is counter-productive, you usually need to build new binutils in order to build new gcc, with this requirement you are forcing everybody to first build new binutils without gold, then new gcc, then build again new binutils and possibly build new gcc again. -- 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 mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/14309] New: gold doesn't build with gcc 4.1.3
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 AssignedTo: i...@airs.com ReportedBy: ja...@redhat.com CC: ccout...@google.com Classification: Unclassified gold/README says: The gold source code uses templates heavily. Building it requires a recent version of g++. g++ 4.0.3 and 4.1.3 are known to work. g++ 3.2, 3.4.3, and 4.1.2 are known to fail. and I used to be able to build 2.22.52.0.1 just fine with gcc-4.1.2-RH (which is based on 137441 of FSF branches/gcc-4_1-branch (no libstdc++ changes on that branch after that revision). But 2.22.52.0.4 no longer builds with it: /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/hashtable: In instantiation of 'Internal::hash_code_baselong long int, std::pairconst long long int, gold::Gdb_index_info_reader::Declaration_pair, Internal::extract1ststd::pairconst long long int, gold::Gdb_index_info_reader::Declaration_pair , std::equal_tolong long int, std::tr1::hashlong long int, Internal::mod_range_hashing, Internal::default_ranged_hash, false': /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/hashtable:1014: instantiated from 'std::tr1::hashtablelong long int, std::pairconst long long int, gold::Gdb_index_info_reader::Declaration_pair, std::allocatorstd::pairconst long long int, gold::Gdb_index_info_reader::Declaration_pair , Internal::extract1ststd::pairconst long long int, gold::Gdb_index_info_reader::Declaration_pair , std::equal_tolong long int, std::tr1::hashlong long int, Internal::mod_range_hashing, Internal::default_ranged_hash, Internal::prime_rehash_policy, false, false, true' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/unordered_map:63: instantiated from 'std::tr1::unordered_maplong long int, gold::Gdb_index_info_reader::Declaration_pair, std::tr1::hashlong long int, std::equal_tolong long int, std::allocatorstd::pairconst long long int, gold::Gdb_index_info_reader::Declaration_pair , false' gdb-index.cc:292: instantiated from here /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/hashtable:863: error: 'Internal::hash_code_baseKey, Value, ExtractKey, Equal, H1, H2, Internal::default_ranged_hash, false::m_h1' has incomplete type /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/functional:1101: error: declaration of 'struct std::tr1::hashlong long int' gdb-index.cc: In constructor 'std::tr1::unordered_mapKey, T, Hash, Pred, Alloc, cache_hash_code::unordered_map(typename std::tr1::hashtableKey, std::pairconst Key, T, Alloc, Internal::extract1ststd::pairconst Key, T , Pred, Hash, Internal::mod_range_hashing, Internal::default_ranged_hash, Internal::prime_rehash_policy, cache_hash_code, false, true::size_type, const typename std::tr1::hashtableKey, std::pairconst Key, T, Alloc, Internal::extract1ststd::pairconst Key, T , Pred, Hash, Internal::mod_range_hashing, Internal::default_ranged_hash, Internal::prime_rehash_policy, cache_hash_code, false, true::hasher, const typename std::tr1::hashtableKey, std::pairconst Key, T, Alloc, Internal::extract1ststd::pairconst Key, T , Pred, Hash, Internal::mod_range_hashing, Internal::default_ranged_hash, Internal::prime_rehash_policy, cache_hash_code, false, true::key_equal, const typename std::tr1::hashtableKey, std::pairconst Key, T, Alloc, Internal::extract1ststd::pairconst Key, T , Pred, Hash, Internal::mod_range_hashing, Internal::default_ranged_hash, Internal::prime_rehash_policy, cache_hash_code, false, true::allocator_type) [with Key = long long int, T = gold::Gdb_index_info_reader::Declaration_pair, Hash = std::tr1::hashlong long int, Pred = std::equal_tolong long int, Alloc = std::allocatorstd::pairconst long long int, gold::Gdb_index_info_reader::Declaration_pair , bool cache_hash_code = false]': gdb-index.cc:189: error: invalid use of undefined type 'struct std::tr1::hashlong long int' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/functional:1101: error: declaration of 'struct std::tr1::hashlong long int' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/hashtable: In member function 'size_t Internal::hash_code_baseKey, Value, ExtractKey, Equal, H1, H2, Internal::default_ranged_hash, false::m_hash_code(const Key) const [with Key = long long int, Value = std::pairconst long long int, gold::Gdb_index_info_reader::Declaration_pair, ExtractKey = Internal::extract1ststd::pairconst long long int, gold::Gdb_index_info_reader::Declaration_pair , Equal = std::equal_tolong long int, H1 = std::tr1::hashlong long int, H2 = Internal::mod_range_hashing]': /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/hashtable:1541: instantiated from 'typename
[Bug ld/13817] New: Broken IFUNC support
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: unassig...@sourceware.org ReportedBy: ja...@redhat.com CC: hjl.to...@gmail.com Classification: Unclassified Target: i386-linux The PR ld/13302 changes broke not only x86_64 (fixed http://sources.redhat.com/ml/binutils-cvs/2012-03/msg00019.html ), but also i386. ifunc3.sh test in prelink fails because of that. The problem is that you just can't on i?86 use a standard PLT entry for what you want to do, because unlike x86_64 in i?86 shared libraries/PIEs the PLT slot assumes that %ebx of the caller points to the _GLOBAL_OFFSET_TABLE_ symbol of the library containing the PLT slot. That is normally the responsibility of the compiler or assembly writer, but in this case where you just have a function pointer that resolves internally to an IFUNC symbol you have no such guarantee. If that function pointer is called from the main binary, %ebx can contain random garbage, if it is called from some other shared library, it will contain address of a different _GLOBAL_OFFSET_TABLE_ symbol. -- 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 mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13817] Broken IFUNC support
http://sourceware.org/bugzilla/show_bug.cgi?id=13817 --- Comment #1 from Jakub Jelinek jakub at redhat dot com 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 PLT calling completely unrelated function). -- 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 mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12921] sh_offset for SHT_NOBITS sections
http://sourceware.org/bugzilla/show_bug.cgi?id=12921 --- Comment #3 from Jakub Jelinek jakub at redhat dot com 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 undo prelink feeds the saved ElfXX_Shdr/ElfXX_Phdr etc. content to libelf to restore the file. And, apparently sh_offset beyond end of file mean at least for elfutils libelf that it pads with zeros up to that spot. Of course one could probably tweak libelf (haven't tried the other implementation how it behaves nor looked how hard would it be), but the question is why is such an sh_offset desirable. When the section has no content in the file (SHT_NOBITS or zero sized section), why can't sh_offset simply be what it used to (either equal to sh_offset of the next section, or of last section + its in the file size)? -- 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 mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12921] sh_offset for SHT_NOBITS sections
http://sourceware.org/bugzilla/show_bug.cgi?id=12921 --- Comment #5 from Jakub Jelinek jakub at redhat dot com 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: --- 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/12921] New: sh_offset for SHT_NOBITS sections
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...@sources.redhat.com
ReportedBy: ja...@redhat.com
A recent change in ld broke prelink.
Eg. on the attached testcase:
struct A { char a; struct A *b; int *c; };
static struct A local = { 77, local, 0 };
int vbss[16384] __attribute__((aligned (4096)));
int vdata __attribute__((aligned (4096))) = 5;
asm (.text; .balign 4096; vtext:; .previous);
int main()
{
asm volatile ( : : m (local), m (vbss[0]), m (vdata));
return 0;
}
we used to emit (e.g. in 2.21.0.51.0.6, but like since forever):
[24] .data PROGBITS00603000 003000 001028 00 WA
0 0 4096
[25] .bss NOBITS 00605000 004028 011000 00 WA
0 0 4096
[26] .comment PROGBITS 004028 58 01 MS
0 0 1
[27] .shstrtab STRTAB 004080 ee 00
0 0 1
but now (2.21.52.0.1) we emit:
[24] .data PROGBITS00603000 003000 002004 00 WA
0 0 4096
[25] .bss NOBITS 00606000 006000 011000 00 WA
0 0 4096
[26] .comment PROGBITS 005004 59 01 MS
0 0 1
[27] .shstrtab STRTAB 00505d ee 00
0 0 1
The problem is that the sh_offset for .bss is no longer smaller or equal to the
next section's sh_offset, but, what's more important, is that it is even way
after the end of the file on disk.
When elfutils libelf tries to write this during prelink --undo, it will write
0x6000 bytes of file instead of just 0x505d+0xee the original file had.
Can this change be please reverted?
--
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 mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12727] New: ld ppc64 bug with dot symbols
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...@sources.redhat.com
ReportedBy: ja...@redhat.com
cat test.c \EOF
extern char *dlerror (void);
volatile int i;
void _start (void)
{
if (dlerror ())
i++;
}
EOF
gcc -c -m64 test.c -o test.o
ld -o test -L . -ldl test.o -lc ./ld64.so.1
ld -o test -L . -ldl test.o -ldl -lc ./ld64.so.1
ld -o test -L . test.o -ldl -lc ./ld64.so.1
gcc -c -m64 -mcall=aixdesc -o test.o
ld -o test -L . -ldl test.o -lc ./ld64.so.1
ld -o test -L . -ldl test.o -ldl -lc ./ld64.so.1
ld -o test -L . test.o -ldl -lc ./ld64.so.1
(this assumes libc.so, libdl.so and ld64.so.1 are in current working directory,
and have been built with gcc that defaults to the new linux ABI (i.e. not
-mcall=aixdesc) and thus doesn't have .dlerror etc. symbols in it).
When test.o is built without dot symbols, all 3 ld commands succeed just fine,
when it is built with dot symbols and libdl.so.2 is not, only the command line
with -ldl solely after test.o succeeds.
Verified with today's CVS HEAD with a cross compiler, cross assembler and cross
linker, and is reported to be also present on RHEL6, which has ld based on
hjl's
2.20.51.0.2. It is reported to succeed on RHEL5, which is based on
2.17.50.0.6.
--
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 mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12727] ld ppc64 bug with dot symbols
http://sourceware.org/bugzilla/show_bug.cgi?id=12727 Jakub Jelinek jakub at redhat dot com changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #1 from Jakub Jelinek jakub at redhat dot com 2011-05-03 11:41:55 UTC --- In the original the dot symbols compiled object was in an *.a library and was dragged in by some other objects, again if -ldl preceeded it on the command line, link would fail. -- 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 mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/12451] New: --build-id regression
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.redhat.com
ReportedBy: ja...@redhat.com
Apparently ld --build-id behavior changed recently, so it no longer checksums
symbol table sections.
A short testcase:
cat A.java \EOF
class A
{
public static void main(String args[])
{
System.out.println(Hello World!);
}
}
EOF
sed s/A/B/ A.java B.java
gcj -C A.java
gcj -C B.java
gcj -shared -fpic -o libAB.so A.class B.class
gcj -o A -fmain=A ./libAB.so -Wl,--build-id
gcj -o B -fmain=B ./libAB.so -Wl,--build-id
objdump -s -j .note.gnu.build-id A B
While with older linkers (e.g. 2.20.51.0.2) the build ids were different
between A and B, in CVS head as well as 2.21.51.0.5 the build ids are the same,
eventhough the binaries are different (although they have exactly the same code
sections, as they call different code they certainly aren't the same).
--
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 mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/12451] --build-id regression
http://sourceware.org/bugzilla/show_bug.cgi?id=12451 Jakub Jelinek jakub at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com, ||roland at redhat 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 mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/12451] --build-id regression
http://sourceware.org/bugzilla/show_bug.cgi?id=12451 --- Comment #1 from Jakub Jelinek jakub at redhat dot com 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 redundant. In elf_checksum_contents it checksums contents of sections guarded with if (i_shdr.contents) Except, at least in my testing, i_shdr.contents is always NULL so it only checksums section headers, program headers and ELF header. -- 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 mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12451] --build-id regression
http://sourceware.org/bugzilla/show_bug.cgi?id=12451 Jakub Jelinek jakub at redhat dot com changed: What|Removed |Added Component|binutils|ld -- 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 mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11434] New: ld resolves relocations against STB_GNU_UNIQUE in DT_SYMBOLIC libraries
int i;
static int * g(void)
{
return i;
}
struct S {
static int * f(void)
{
static int *p = g();
return p;
}
};
int * wrap2_f (void)
{
return S::f();
}
g++ -O2 -fpic -shared -o lib.so lib.cc -Wl,-Bsymbolic
(assuming gcc has been configured to use STB_GNU_UNIQUE).
There are no relocations against _ZZN1S1fEvE1p (STB_GNU_UNIQUE) symbol defined
in this library. While for non-STB_GNU_UNIQUE symbols that's desirable, the
symbol will always resolve to the containing library, for STB_GNU_UNIQUE it
causes the symbol to be no longer unique in the whole program.
--
Summary: ld resolves relocations against STB_GNU_UNIQUE in
DT_SYMBOLIC libraries
Product: binutils
Version: 2.21 (HEAD)
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,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 list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10911] New: ld -s -static breaks IRELATIVE relocations
.text .type foo, @gnu_indirect_function .globl foo foo: leaq __foo(%rip), %rax retq .type __foo, @function __foo: retq .type _start, @function .globl _start _start: call foo 1: jmp 1b $ as -o t.o t.s $ ld -static -o t t.o $ readelf -Wr t Relocation section '.rela.plt' at offset 0xb0 contains 1 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 006000e8 0025 R_X86_64_IRELATIVE 004000d8 $ strip t $ readelf -Wr t Relocation section '.rela.plt' at offset 0xb0 contains 1 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 006000e8 0025 R_X86_64_IRELATIVE 004000d8 $ ld -static -s -o t t.o Relocation section '.rela.plt' at offset 0xb0 contains 1 entries: Offset Info Type Symbol's Value Symbol's Name + Addend R_X86_64_NONE While this minimal testcase won't work in any case, when actually linking a real program (say replace _start with main and link with -lc), the program will die because of unexpected reloc type in statically linked binary. -- Summary: ld -s -static breaks IRELATIVE relocations Product: binutils Version: 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://sourceware.org/bugzilla/show_bug.cgi?id=10911 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10492] New: strip -g breaks objects with STB_GNU_UNIQUE
cat x.s \EOF .section.data.rel.ro,aw,@progbits .align 16 .type_ZZ3fooiE1t, @object .size_ZZ3fooiE1t, 16 _ZZ3fooiE1t: .quad_ZN1AIiE1aE .quad0 .weak_ZN1AIiE1aE .section.rodata._ZN1AIiE1aE,aG,@progbits,_ZN1AIiE1aE,comdat .align 4 .type_ZN1AIiE1aE, @gnu_unique_object .size_ZN1AIiE1aE, 4 _ZN1AIiE1aE: .long16 .section.note.GNU-stack,,@progbits EOF sed 's/foo/bar/g' x.s y.s gas/as-new -o x.o x.s gas/as-new -o y.o y.s ld/ld-new -shared -nostdlib -o x.so x.o y.o; echo $? cp -a y.o z.o binutils/strip-new -g z.o ld/ld-new -shared -nostdlib -o x.so x.o z.o; echo $? The first link is fine, but the second complains. 0 `_ZN1AIiE1aE' referenced in section `.data.rel.ro' of z.o: defined in discarded section `.rodata._ZN1AIiE1aE[_ZN1AIiE1aE]' of z.o 1 The only difference is that one of the objects has been strip -g'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 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=10492 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10492] strip -g breaks objects with STB_GNU_UNIQUE
--- 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 other LOCAL symbols. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10492 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10492] strip -g breaks objects with STB_GNU_UNIQUE
--- 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=4114action=view) binutils-bz10492.patch Indeed, you're right. Following patch cures it. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10492 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10433] New: Latest ld fails to link ldconfig properly
See attached tarball, when linked with latest ld, ./ldconfig --help segfaults. _nl_make_l10nflist calls stpcpy, yet __stpncpy_ssse3 is actually called. -- Summary: Latest ld fails to link ldconfig properly Product: binutils Version: 2.20 (HEAD) 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,hjl dot tools at gmail dot com GCC target triplet: x86_64-linux http://sourceware.org/bugzilla/show_bug.cgi?id=10433 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10433] Latest ld fails to link ldconfig properly
--- 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 on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10433] Latest ld fails to link ldconfig properly
--- 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 Symbol's Value Symbol's Name + Addend 006c65d0 0025 R_X86_64_IRELATIVE 00421a50 006c65d8 0025 R_X86_64_IRELATIVE 0041f720 006c65e0 0025 R_X86_64_IRELATIVE 00423a30 006c65e8 0025 R_X86_64_IRELATIVE 00423a30 006c65f0 0025 R_X86_64_IRELATIVE 00423ed0 006c65f8 0025 R_X86_64_IRELATIVE 00479060 006c6600 0025 R_X86_64_IRELATIVE 0041e760 006c6608 0025 R_X86_64_IRELATIVE 0047a030 where 2532: 0047a03068 IFUNC WEAK DEFAULT6 stpncpy 1394: 00421a5068 IFUNC WEAK DEFAULT6 stpcpy But when linked with trunk, this is: 006c65d0 0025 R_X86_64_IRELATIVE 0047a030 006c65d8 0025 R_X86_64_IRELATIVE 0041f720 006c65e0 0025 R_X86_64_IRELATIVE 00423a30 006c65e8 0025 R_X86_64_IRELATIVE 00423a30 006c65f0 0025 R_X86_64_IRELATIVE 00423ed0 006c65f8 0025 R_X86_64_IRELATIVE 00479060 006c6600 0025 R_X86_64_IRELATIVE 0041e760 006c6608 0025 R_X86_64_IRELATIVE 0047a030 and the symbols are the same. And indeed, the only changes between the two binaries are 3 bytes in .rela.plt section: Relocation section '.rela.plt' at offset 0x1a0 contains 8 entries: Offset Info Type Symbol's Value Symbol's Name + Addend -006c65d0 0025 unrecognized: 25 0047a030 +006c65d0 0025 unrecognized: 25 00421a50 and content of .note.gnu.build-id section. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10433 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10426] New: ld incorrectly creates STT_GNU_IFUNC SHN_UNDEF symbols
See https://bugzilla.redhat.com/show_bug.cgi?id=512937
No SHN_UNDEF symbols should ever have STT_GNU_IFUNC type, they should be
STT_FUNC instead. Whether a symbol in the shared library some other shared
library or binary is linked dynamically against is STT_GNU_IFUNC or not doesn't
say anything about whether it will be actually indirect or direct function call
at runtime. IFUNC is always only a property of a symbol definition.
Especially for PLT SHN_UNDEF symbols with non-zero st_value this is fatal
problem, see e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=512078
Testcase:
BINUTILS_OBJ=/usr/src/binutils/obj
BINUTILS_SRC=/usr/src/binutils
gcc -B$BINUTILS_OBJ/ld/tmpdir/gas/ -I$BINUTILS_SRC/ld/testsuite/ld-ifunc -g
-O2 \
-c -fPIC -DWITH_IFUNC -c $BINUTILS_SRC/ld/testsuite/ld-ifunc/lib.c \
-o shared_ifunc.o
$BINUTILS_OBJ/ld/ld-new -o libshared_ifunc.so -shared shared_ifunc.o
echo 'extern int library_func2 (void);' test.c
echo 'int main (void) { library_func2 (); return 0; }' test.c
gcc -B $BINUTILS_OBJ/ld/tmpdir/ld/ -o test test.c ./libshared_ifunc.so
$BINUTILS_OBJ/binutils/readelf -Ws test | grep IFUNC.*UND
echo 'extern int library_func2 (void);' test2.c
echo 'int (*fn) (void) = library_func2;' test2.c
echo 'int main (void) { fn (); return 0; }' test2.c
gcc -B $BINUTILS_OBJ/ld/tmpdir/ld/ -o test2 test2.c ./libshared_ifunc.so
$BINUTILS_OBJ/binutils/readelf -Ws test2 | grep IFUNC.*UND
Should print nothing, prints:
1: 0 IFUNC GLOBAL DEFAULT UND library_func2
49: 0 IFUNC GLOBAL DEFAULT UND library_func2
5: 00400458 0 IFUNC GLOBAL DEFAULT UND library_func2
49: 00400458 0 IFUNC 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
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
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.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10426] ld incorrectly creates STT_GNU_IFUNC SHN_UNDEF symbols
--- 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. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10337] strip breaks statically linked binaries with .rela.plt section
-- What|Removed |Added CC||hjl dot tools at gmail dot ||com http://sourceware.org/bugzilla/show_bug.cgi?id=10337 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10337] New: strip breaks statically linked binaries with .rela.plt section
On --enable-multiarch configured glibc if I do: elf/ldconfig --version; \ /usr/src/binutils/obj/binutils/strip-new elf/ldconfig; \ elf/ldconfig --version I get: ldconfig (GNU libc) 2.10.90 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Andreas Jaeger. unexpected reloc type in static binaryAborted Before stripping we have: ... [ 2] .note.gnu.build-id NOTE00400178 000178 24 00 A 0 0 4 [ 3] .rela.plt RELA004001a0 0001a0 30 18 A 0 5 8 [ 4] .init PROGBITS004001d0 0001d0 18 00 AX 0 0 4 [ 5] .plt PROGBITS004001e8 0001e8 20 00 AX 0 0 4 ... 1373: 004001d0 0 NOTYPE LOCAL HIDDEN3 __rela_iplt_end 1374: 006b1030 0 NOTYPE LOCAL HIDDEN 17 __fini_array_end 1375: 004001a0 0 NOTYPE LOCAL HIDDEN3 __rela_iplt_start after stripping: [ 2] .note.gnu.build-id NOTE00400178 000178 24 00 A 0 0 4 [ 3] .plt PROGBITS004001e8 0001e8 20 00 AX 0 0 4 [ 4] .rela.plt RELA 0b6588 00 18 0 3 8 [ 5] .init PROGBITS004001d0 0001d0 18 00 AX 0 0 4 (note non-allocated RELA section) and all 48 bytes between 0x1a0 and 0x1d0 in the file are cleared. -- Summary: strip breaks statically linked binaries with .rela.plt section Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 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 this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/10269] New: IFUNC gas problem
#ifndef PICKNO
# define PICKNO 1
#endif
#if PICKNO == 2
# define PICK(fn1, fn2) #fn2
#else
# define PICK(fn1, fn2) #fn1
#endif
#ifdef __x86_64__
# define IFUNC_ASM(fn) \tleaq fn (%rip), %rax\n\tretq\n
#endif
#define IFUNC(name, globl, fn1, fn2) \
extern __typeof (fn1) fn1 __attribute__((used));\
extern __typeof (fn2) fn2 __attribute__((used));\
extern __typeof (fn1) name;\
asm (globl #name \n\
\t.type #name , @gnu_indirect_function\n\
#name :\n\
IFUNC_ASM (PICK (fn1, fn2))\
\t.size #name , .- #name \n)
#define IFUNC_LOCAL(name, fn1, fn2) IFUNC(name, .local, fn1, fn2)
#define IFUNC_GLOBAL(name, fn1, fn2) IFUNC(name, .globl, fn1, fn2)
static int foo1 (void) { return 1; }
static int foo2 (void) { return 2; }
IFUNC_LOCAL (foo, foo1, foo2);
extern void abort (void);
int
main (void)
{
if (foo () != PICKNO)
abort ();
return 0;
}
In this case IMHO gas should create R_*_IRELATIVE relocation against the local
foo symbol. If foo is .globl or .globl and .hidden, it works correctly.
--
Summary: IFUNC 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: bug-binutils at gnu dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=10269
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10270] New: IFUNC local symbol
See ifunc3 testcase in http://sources.redhat.com/ml/binutils/2009-06/msg00199.html If binary overrides some shared library's symbol with its STT_GNU_IFUNC symbol and the binary takes address of that symbol, the symbol defined in the binary shouldn't be IMHO STT_GNU_IFUNC pointing to the indirect function, but normal symbol pointing to the PLT slot (which will have R_*_IRELATIVE relocation for its .got.plt), otherwise pointer comparisons don't work well. -- Summary: IFUNC local symbol Product: binutils Version: 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 http://sourceware.org/bugzilla/show_bug.cgi?id=10270 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10270] IFUNC local symbol
--- 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 contain the resolved function that should be called, so in that (hopefully rare, IFUNC doesn't make as much sense in the binaries as it does in shared libraries and binary overriding symbols in shared libraries is also not so common) case calls from the shared library need to hop through two .plt slots. But I don't see other ways how to make pointer comparisons work in this case. Obviously if the binary doesn't take its address, using IFUNC symbol in the binary is just fine. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10270 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10270] IFUNC local symbol
-- What|Removed |Added CC||drepper at redhat dot com, ||roland at redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=10270 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10255] no .eh_frame_hdr table will be created.
--- 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=3988action=view) z2.s.bz2 This looks like a gas bug to me. At least from brief look at .cfi_* directives in the assembly they look ok, but after assembling we see: 0044 002c 0048 FDE cie= pc=339f..00016d6a DW_CFA_advance_loc: 1 to 33a0 DW_CFA_def_cfa_offset: 16 DW_CFA_advance_loc: 3 to 33a3 DW_CFA_offset: r6 (rbp) at cfa-16 DW_CFA_def_cfa_register: r6 (rbp) DW_CFA_advance_loc2: 332 to 34ef DW_CFA_offset: r3 (rbx) at cfa-56 DW_CFA_offset: r12 (r12) at cfa-48 DW_CFA_offset: r13 (r13) at cfa-40 DW_CFA_offset: r14 (r14) at cfa-32 DW_CFA_offset: r15 (r15) at cfa-24 DW_CFA_nop DW_CFA_advance_loc: 58 to 3529 DW_CFA_??? (User defined call frame op: 0x38) in the second FDE. I guess gas just doesn't handle the huge location advance well (from 34ef to 16d69). Looking into it... -- http://sourceware.org/bugzilla/show_bug.cgi?id=10255 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10255] no .eh_frame_hdr table will be created.
--- 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 because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/10255] no .eh_frame_hdr table will be created.
-- What|Removed |Added AssignedTo|unassigned at sources dot |jakub at redhat dot com |redhat dot com | Status|NEW |ASSIGNED Component|ld |gas http://sourceware.org/bugzilla/show_bug.cgi?id=10255 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6443] -pie issues with TLS relocations
--- 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 that, as you don't know how big the executable or PIE's TLS block will be, what alignment will it need etc., so for those you need a runtime relocation. If gcc on ppc/ppc64 reschedules insns and violates the TLS ABI, then it should be fixed. E.g. on i?86/x86_64 we use multiple asm insns in one define_insn to make sure that something that must be kept consecutive isn't scattered around. See e.g. tls_global_dynamic_64, tls_local_dynamic_base_64, tls_global_dynamic_32_gnu etc. in i386.md. But for fixing this particular bug you could perhaps leave out the local-dynamic and global-dynamic in the testcase, that was added just for completeness. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6443 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6443] -pie issues with TLS relocations
--- 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 000c 000c0017 R_X86_64_TPOFF32 a + 0 0014 000d0017 R_X86_64_TPOFF32 0004 b + 0 001e 000e0014 R_X86_64_TLSLD 000c d + fffc 0023 000f0004 R_X86_64_PLT32 __tls_get_addr + fffc 0029 000e0015 R_X86_64_DTPOFF32 000c d + 0 0031 00100013 R_X86_64_TLSGD 0010 e + fffc 0039 000f0004 R_X86_64_PLT32 __tls_get_addr + fffc and all of them can and should be in a PIE transitioned to the fastest, local-exec, ones, as all resolve to a symbol within the PIE. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6443 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6443] -pie issues with TLS relocations
--- 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=2715action=view) bz6443.patch Attached is just very lightly tested x86_64 set of changes, but i386, ppc, ppc64 and other arches need similar changes. For now glibc will use a workaround, but it would be good to have this fixed soon. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6443 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6443] -pie issues with TLS relocations
-- What|Removed |Added CC||drepper at redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=6443 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/3290] Linker creates dynamic debug symbols in DSO
--- 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, ld -r
on one or more *.o files which define such global symbols will make those
symbols STB_LOCAL and so a final link fails. IMHO either the debug symbols
should be made global, but hidden, or made local only when not ld -r.
--- bfd/elflink.c 2 Mar 2008 22:26:09 - 1.299
+++ bfd/elflink.c 25 Mar 2008 15:01:19 -
@@ -4294,7 +4294,7 @@ elf_link_add_object_symbols (bfd *abfd,
dynsym = TRUE;
}
- if (definition (sec-flags SEC_DEBUGGING))
+ if (definition (sec-flags SEC_DEBUGGING) !info-relocatable)
{
/* We don't want to make debug symbol dynamic. */
(*bed-elf_backend_hide_symbol) (info, h, TRUE);
works for me.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3290
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug libc/4781] binutils 2.17.50.0.7 and later eats up memory when calling gnujava wizards in OpenOffice
--- 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 I have reverted Jan's glibc patch on fedora-branch and so didn't ever see it again). -- http://sourceware.org/bugzilla/show_bug.cgi?id=4781 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4781] binutils 2.17.50.0.7 and later eats up memory when calling gnujava wizards in OpenOffice
--- 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 binutils issue. What I'd try is back out http://sources.redhat.com/ml/glibc-cvs/2006-q4/msg00364.html in glibc sources, see http://gcc.gnu.org/ml/gcc/2006-12/msg00293.html -- http://sourceware.org/bugzilla/show_bug.cgi?id=4781 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4781] binutils 2.17.50.0.7 and later eats up memory when calling gnujava wizards in OpenOffice
--- 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. So, please pack up: elf/ld.so libc.map libc_pic.a libc_pic.os shlib.lds csu/abi-note.o elf/soinit.os elf/sofini.os elf/interp.os in your glibc build directory and your `gcc -print-file-name=libgcc.a` and attach it as a bzip2ed tarball here as attachment. Also mention the exact ld command line that was used to link your libc.so - rerun the gcc -shared -static-libgcc -o /libc.so command from your glibc build log with additional -v and past the collect2 command line here. Thanks. -- What|Removed |Added Status|NEW |WAITING http://sourceware.org/bugzilla/show_bug.cgi?id=4781 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/4409] New: --unresolved-symbols=ignore-all issues on ia64
cat a.c EOF
extern int foo (void);
int
main (void)
{
return foo ();
}
EOF
gcc -fpie -pie --unresolved-symbols=ignore-all a.c -o a
segfaults in the linker on
/* Since there's no PLT entry, Validate that this is
locally defined. */
BFD_ASSERT (undef_weak_ref || sym_sec-output_section != NULL);
(sym_sec is apparently NULL).
--
Summary: --unresolved-symbols=ignore-all issues on ia64
Product: binutils
Version: 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: ia64-linux
http://sourceware.org/bugzilla/show_bug.cgi?id=4409
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/2721] New: --as-needed vs. DT_NEEDED undef symbols checks
echo 'int foo1;' | gcc -shared -fpic -o /usr/lib/libfoo.so -xc - -xnone
-Wl,-soname,libfoo.so
echo 'int foo1; int foo2;' | gcc -shared -fpic -o libfoo.so -xc - -xnone
-Wl,-soname,libfoo.so
echo 'int foo (void) { extern int foo2; return foo2; }' | gcc -shared -fpic -o
libbar.so -xc - -xnone ./libfoo.so
echo 'extern int foo (void); int main (void) { return foo (); }' \
| gcc -o test -xc - -xnone -Wl,--as-needed ./libfoo.so ./libbar.so
-Wl,--no-as-needed
fails to link because foo2 is undefined.
Withouth -Wl,--as-needed this links just fine (and so does adding
-Wl,--rpath-link,.), but I don't think --as-needed should make a difference
whether something links or not and what the above script does is something
that happens quite often - a project with several libraries adds a new symbol to
one of them and as the library is explicitly listed on the command line, the
user shouldn't be really requested to supply a rpath-link as well.
The problem I'd say is in
gld${EMULATION_NAME}_check_needed
which ignores --as-needed libraries:
/* If this input file was an as-needed entry, and wasn't found to be
needed at the stage it was linked, then don't say we have loaded it. */
if (s-as_needed
(s-the_bfd == NULL
|| (bfd_elf_get_dyn_lib_class (s-the_bfd) DYN_AS_NEEDED) != 0))
return;
I think it should in this case either load that library again (as in, call
gld${EMULATION_NAME}_try_needed on the same filename), or just mark the library
not only DYN_AS_NEEDED, but also DYN_DT_NEEDED and handle that combination of
flags.
--
Summary: --as-needed vs. DT_NEEDED undef symbols checks
Product: binutils
Version: 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
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 are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/2721] --as-needed vs. DT_NEEDED undef symbols checks
--- 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 -o /usr/lib/libfoo.so -xc - -xnone \
-Wl,-soname,libfoo.so
echo 'int foo1; int foo2;' | gcc -shared -fpic -o libfoo.so -xc - -xnone \
-Wl,-soname,libfoo.so
echo 'int foo (void) { extern int foo2; return foo2; }' \
| gcc -shared -fpic -o libbar.so -xc - -xnone ./libfoo.so
echo 'extern int foo (void); int main (void) { return foo (); }' \
| gcc -o test -xc - -xnone -Wl,--as-needed ./libbar.so ./libfoo.so \
-Wl,--no-as-needed
--
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 are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/2721] --as-needed vs. DT_NEEDED undef symbols checks
--- 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 are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
