[Bug ld/21368] how to succesfully build program in MinGW without this interrupting
https://sourceware.org/bugzilla/show_bug.cgi?id=21368 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-04-11 Assignee|unassigned at sourceware dot org |nickc at redhat dot com Ever confirmed|0 |1 --- Comment #3 from Nick Clifton --- Created attachment 9981 --> https://sourceware.org/bugzilla/attachment.cgi?id=9981&action=edit Proposed patch Hi Budi, > on Windows 64bit by loading the source from Github, then after completing > all Msys2 & Mingw64, A ha! I think that this is the clue. The mingw64 version of the linker does not support the --large-address-aware command line option because it is already large address aware. Ie you do not need an option to turn it on, and, more significantly, you cannot use --disable-large-address-aware to turn it off. So... the problem is with the how your build is being configured. Something is addding the --large-address-aware option to the linker command line, when it really should not. I know how difficult it can be to track down and fix build configuration problems however, so as an alternative I am uploading a small patch for you to try out. (Assuming that you are able to build your own version of the linker). This patch makes the mingw64 silently accept the --large-address-aware option. It does not do anything - there is nothing to be done - but at least now the linker will not complain about an unrecognised option. If you are able, please give this patch a test and let me know if it solves the problem for you. Alternatively you could track down the problem in your configuration system and fix that. Cheers Nick -- 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/21368] how to succesfully build program in MinGW without this interrupting
https://sourceware.org/bugzilla/show_bug.cgi?id=21368 --- Comment #4 from Budi --- don't laugh at me.. but I frankly don't understand the patch script, is it a kind of 'makefile' language ? What I have in mind now is just how to move our conversation to a forum that is heard and learnt by many more users, to be more benefit. On Tue, Apr 11, 2017 at 3:19 PM, nickc at redhat dot com < sourceware-bugzi...@sourceware.org> wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=21368 > > Nick Clifton changed: > >What|Removed |Added > > > Status|UNCONFIRMED |ASSIGNED >Last reconfirmed||2017-04-11 >Assignee|unassigned at sourceware dot org |nickc at redhat > dot com > Ever confirmed|0 |1 > > --- Comment #3 from Nick Clifton --- > Created attachment 9981 > --> https://sourceware.org/bugzilla/attachment.cgi?id=9981&action=edit > Proposed patch > > Hi Budi, > > > on Windows 64bit by loading the source from Github, then after completing > > all Msys2 & Mingw64, > > A ha! I think that this is the clue. The mingw64 version of the linker > does > not support the --large-address-aware command line option because it is > already > large address aware. Ie you do not need an option to turn it on, and, more > significantly, you cannot use --disable-large-address-aware to turn it off. > > So... the problem is with the how your build is being configured. > Something is > addding the --large-address-aware option to the linker command line, when > it > really should not. > > I know how difficult it can be to track down and fix build configuration > problems however, so as an alternative I am uploading a small patch for > you to > try out. (Assuming that you are able to build your own version of the > linker). > This patch makes the mingw64 silently accept the --large-address-aware > option. > It does not do anything - there is nothing to be done - but at least now > the > linker will not complain about an unrecognised option. > > If you are able, please give this patch a test and let me know if it > solves the > problem for you. Alternatively you could track down the problem in your > configuration system and fix that. > > Cheers > Nick > > -- > You are receiving this mail because: > You reported the bug. > -- 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/18466] too long symbol names in def files are causing the linker to crash
https://sourceware.org/bugzilla/show_bug.cgi?id=18466 --- Comment #5 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=fbea15088db59186960134d11b8bf98070224d6c commit fbea15088db59186960134d11b8bf98070224d6c Author: Alan Modra Date: Tue Apr 11 19:37:51 2017 +0930 PR 21274, ld segfaults linking PE DLL Don't use fixed size buffers for symbol names. PR 21274 PR 18466 * emultempl/pe.em (pe_find_data_imports): Don't use fixed size symbol buffer. Instead, xmalloc max size needed with space for prefix. Wrap overlong lines. Formatting. Pass symbol buffer copy of name to pe_walk_relocs_of_symbol. (make_inport_fixup): Add "name" param, pass to pe_create_import_fixup. * emultempl/pe.em (pep_find_data_imports): As for pe_find_data_imports. (make_import_fixup): Add "name" param, pass to pep_create_import_fixup. Use bfd_get_signed_* and remove unnecessary casts. Formatting. * pe-dll.c (pe_walk_relocs_of_symbol): Add "name" param. Pass to callback. (make_import_fixup_mark): Add "name" param. Make use of prefix space rather than xmalloc here. (pe_create_import_fixup): Likewise. * pe-dll.h (pe_walk_relocs_of_symbol): Update prototype. (pe_create_import_fixup): Likewise. * pep-dll.h (pep_walk_relocs_of_symbol): Likewise. (pep_create_import_fixup): Likewise. -- 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/21274] ld segfaults linking PE DLL
https://sourceware.org/bugzilla/show_bug.cgi?id=21274 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=fbea15088db59186960134d11b8bf98070224d6c commit fbea15088db59186960134d11b8bf98070224d6c Author: Alan Modra Date: Tue Apr 11 19:37:51 2017 +0930 PR 21274, ld segfaults linking PE DLL Don't use fixed size buffers for symbol names. PR 21274 PR 18466 * emultempl/pe.em (pe_find_data_imports): Don't use fixed size symbol buffer. Instead, xmalloc max size needed with space for prefix. Wrap overlong lines. Formatting. Pass symbol buffer copy of name to pe_walk_relocs_of_symbol. (make_inport_fixup): Add "name" param, pass to pe_create_import_fixup. * emultempl/pe.em (pep_find_data_imports): As for pe_find_data_imports. (make_import_fixup): Add "name" param, pass to pep_create_import_fixup. Use bfd_get_signed_* and remove unnecessary casts. Formatting. * pe-dll.c (pe_walk_relocs_of_symbol): Add "name" param. Pass to callback. (make_import_fixup_mark): Add "name" param. Make use of prefix space rather than xmalloc here. (pe_create_import_fixup): Likewise. * pe-dll.h (pe_walk_relocs_of_symbol): Update prototype. (pe_create_import_fixup): Likewise. * pep-dll.h (pep_walk_relocs_of_symbol): Likewise. (pep_create_import_fixup): Likewise. -- 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/21274] ld segfaults linking PE DLL
https://sourceware.org/bugzilla/show_bug.cgi?id=21274 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version|unspecified |2.28 Resolution|--- |FIXED Target Milestone|--- |2.29 Severity|critical|normal --- Comment #7 from Alan Modra --- Fixed -- 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
Re: relocation information disappears
> I assume that you mean "readelf -D -r w" here, as you are looking for
dynamic relocs ?
...
96e4 0b14 R_ARM_COPY96e4 debug_f
found.
> What happens when you run the compiled w.c test program ? Is there a
seg-fault for
> accessing memory at address 0 ?
Yes.
I switched to uclibc.
libw.c
int debug_f = 1;
> /opt/arm-epson_uclibc2/bin/arm-none-linux-uclibcgnueabi-gcc
-march=armv7-a -shared -fPIC -o libw.so libw.c
> LD_PRELOAD=./libw.so ./w
Segmentation fault
> gdb w
(gdb) set environment LD_PRELOAD=./libw.so
(gdb) b main
Breakpoint 1 at 0x10490
(gdb) run
Starting program: /opt/w
Breakpoint 1, 0x00010490 in main ()
(gdb) info proc map
process 414
Mapped address spaces:
Start Addr End Addr Size Offset objfile
0x10x11000 0x10000x0 /opt/w
0x20x21000 0x10000x0 /opt/w
0x4007b000 0x4007c000 0x10000x0
0x40094000 0x40095000 0x10000x0
0x400de000 0x400e5000 0x70000x0 /lib/ld-uClibc-1.0.12.so
0x400f4000 0x400f5000 0x1000 0x6000 /lib/ld-uClibc-1.0.12.so
0x400f5000 0x400f6000 0x1000 0x7000 /lib/ld-uClibc-1.0.12.so
0x400f6000 0x401b60000xc0x0 /lib/libuClibc-1.0.12.so
0x401b6000 0x401c5000 0xf0000x0
0x401c5000 0x401c6000 0x10000xbf000 /lib/libuClibc-1.0.12.so
0x401c6000 0x401c7000 0x10000xc /lib/libuClibc-1.0.12.so
0x401c7000 0x401cb000 0x40000x0
0x40227000 0x40228000 0x10000x0 /opt/libw.so
0x40228000 0x40237000 0xf0000x0
0x40237000 0x40238000 0x10000x0 /opt/libw.so
0xbefa8000 0xbefc90000x210000x0 [stack]
0x 0x1000 0x10000x0 [vectors]
(gdb) info shared
>FromTo Syms Read Shared Object Library
0x400dee10 0x400e4348 Yes (*) /lib/ld-uClibc.so.0
0x402273cc 0x4022759c Yes ./libw.so
0x40100090 0x40180728 Yes (*) /lib/libc.so.1
(*): Shared library is missing debugging information.
(gdb) disassemble main
Dump of assembler code for function main:
0x0001047c <+0>: push{r11, lr}
0x00010480 <+4>: add r11, sp, #4
0x00010484 <+8>: sub sp, sp, #8
0x00010488 <+12>:str r0, [r11, #-8]
0x0001048c <+16>:str r1, [r11, #-12]
=> 0x00010490 <+20>:movwr3, #0 <- debug_f
0x00010494 <+24>:movtr3, #0 <- debug_f
0x00010498 <+28>:ldr r3, [r3]
0x0001049c <+32>:mov r1, r3
0x000104a0 <+36>:movwr0, #1228 ; 0x4cc
0x000104a4 <+40>:movtr0, #1
0x000104a8 <+44>:bl 0x102fc
0x000104ac <+48>:mov r3, #0
0x000104b0 <+52>:mov r0, r3
0x000104b4 <+56>:sub sp, r11, #4
0x000104b8 <+60>:pop {r11, pc}
End of assembler dump.
(gdb)
Looking at the assembly code, I think that movw, movt should be rewritten.
Are two instructions rewritten with one R_ARM_COPY?
But R_ARM_MOVW_ABS_NC/R_ARM_MOVT_ABS processing is not in glibc
and uclibc .
Where is wrong?
In Ubuntu 16.10 (amd64)
> lsb_release -a
No LSB modules are available.
Distributor ID:Ubuntu
Description:Ubuntu 16.10
Release:16.10
Codename:yakkety
> gcc --version
gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
Copyright (C) 2016 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.
> ld --version
GNU ld (GNU Binutils for Ubuntu) 2.27
Copyright (C) 2016 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later
version.
This program has absolutely no warranty.
> gcc -o w w.c
> gcc -shared -fPIC -o libw.so libw.c
> LD_PRELOAD=./libw.so ./w
debug 1
As expected.
Movement is different between ARM and X86(amd64).
Katsuya TANAKA.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
Bug report
Hello, I seem to have found a bug in GNU as, when using the intel syntax on x86_64, for some mov instructions, as explained below. I looked into the archive, and could not find a mention of this bug. You'll find two source files attached. Best regards, Sébastien Dusuel - The att syntax has no problem: # cat mov_att.s /* as -o mov_att.o mov_att.s && ld -o mov_att mov_att.o */ .global _start _start: mov %rax, 0x10(%rbp) mov %ebx, 0x20(%rbx) mov %ax, 0x30(%rcx) mov %cl, 0x40(%rdx) # as -o mov_att.o mov_att.s && ld -o mov_att mov_att.o # gdb -q mov_att Reading symbols from mov_att...(no debugging symbols found)...done. (gdb) disassemble _start Dump of assembler code for function _start: 0x00400078 <+0>: mov%rax,0x10(%rbp) 0x0040007c <+4>: mov%ebx,0x20(%rbx) 0x0040007f <+7>: mov%ax,0x30(%rcx) 0x00400083 <+11>: mov%cl,0x40(%rdx) End of assembler dump. - But the intel syntax has a problem: # cat mov_intel.s /* as -o mov_intel.o mov_intel.s && ld -o mov_intel mov_intel.o */ .intel_syntax noprefix .global _start _start: mov qword [rbp + 0x10], rax mov dword [rbx + 0x20], ebx mov word [rcx + 0x30], ax mov byte [rdx + 0x40], cl # as -o mov_intel.o mov_intel.s && ld -o mov_intel mov_intel.o # gdb -q mov_intel Reading symbols from mov_intel...(no debugging symbols found)...done. (gdb) disassemble _start Dump of assembler code for function _start: 0x00400078 <+0>: mov%rax,0x18(%rbp) 0x0040007c <+4>: mov%ebx,0x24(%rbx) 0x0040007f <+7>: mov%ax,0x32(%rcx) 0x00400083 <+11>: mov%cl,0x41(%rdx) End of assembler dump. As you can see, the numerical shifts are not properly treated when using the intel syntax. - The above has been tested on the three following setups: # setup 1: # uname -a Linux kali 4.9.0-kali3-amd64 #1 SMP Debian 4.9.18-1kali1 (2017-04-04) x86_64 GNU/Linux # as --version GNU assembler (GNU Binutils for Debian) 2.28 Copyright (C) 2017 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-linux-gnu'. # setup 2: $ uname -a Linux *** 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux $ as --version GNU assembler (GNU Binutils for Ubuntu) 2.26.1 Copyright (C) 2015 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-linux-gnu'. # setup 3: # uname -a Linux *** 4.4.8-hardened-r1 #4 SMP Sat Oct 22 13:48:12 CEST 2016 x86_64 GNU/Linux # as --version GNU assembler (GNU Binutils for Debian) 2.25 Copyright (C) 2014 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-linux-gnu'. mov_att.s Description: Binary data mov_intel.s Description: Binary data ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/21368] how to succesfully build program in MinGW without this interrupting
https://sourceware.org/bugzilla/show_bug.cgi?id=21368 --- Comment #5 from Nick Clifton --- Hi Budi, > don't laugh at me.. Never. I fully understand that all of this is very technical and can be quite overwhelming for someone not familiar with the workings of open source projects. > but I frankly don't understand the patch script, is it > a kind of 'makefile' language ? Not really. It is the input for a program called "patch" which is used to modify source files: https://en.wikipedia.org/wiki/Patch_(Unix) > What I have in mind now is just how to move our conversation to a forum > that is heard and learnt by many more users, to be more benefit. OK - what do you have in mind ? Cheers Nick -- 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/21373] New: intel syntax on x86_64 offset miscalculation
https://sourceware.org/bugzilla/show_bug.cgi?id=21373 Bug ID: 21373 Summary: intel syntax on x86_64 offset miscalculation Product: binutils Version: 2.29 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: amodra at gmail dot com Target Milestone: --- >From http://lists.gnu.org/archive/html/bug-binutils/2017-04/msg00079.html Assembling the following on x86_64-linux .att_syntax noprefix mov rax, 0x10(rbp) mov ebx, 0x20(rbx) mov ax, 0x30(rcx) mov cl, 0x40(rdx) .intel_syntax noprefix mov qword [rbp + 0x10], rax mov dword [rbx + 0x20], ebx mov word [rcx + 0x30], ax mov byte [rdx + 0x40], cl produces <.text>: 0: 48 89 45 10 mov%rax,0x10(%rbp) 4: 89 5b 20mov%ebx,0x20(%rbx) 7: 66 89 41 30 mov%ax,0x30(%rcx) b: 88 4a 40mov%cl,0x40(%rdx) e: 48 89 45 18 mov%rax,0x18(%rbp) 12: 89 5b 24mov%ebx,0x24(%rbx) 15: 66 89 41 32 mov%ax,0x32(%rcx) 19: 88 4a 41mov%cl,0x41(%rdx) Notice the register size offset miscalculation for intel syntax. -- 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
Re: Bug report
On Tue, Apr 11, 2017 at 10:48:06AM +0200, Sébastien Dusuel wrote: > I seem to have found a bug in GNU as, when using the intel syntax on x86_64, Indeed you have. I have opened https://sourceware.org/bugzilla/show_bug.cgi?id=21373 to track this issue. -- Alan Modra Australia Development Lab, IBM ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21373] intel syntax on x86_64 offset miscalculation
https://sourceware.org/bugzilla/show_bug.cgi?id=21373 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED CC||hjl.tools at gmail dot com Resolution|--- |INVALID --- Comment #1 from H.J. Lu --- It is normal since byte == 1, word == 2, dword == 4 and qword == 8 when they are treated as immediate in "imm [reg + disp]". You can add "ptr" after "imm" to avoid it. -- 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/21375] New: MIPS: Non-zero run-time value produced for PIC references to undefined hidden or internal weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=21375
Bug ID: 21375
Summary: MIPS: Non-zero run-time value produced for PIC
references to undefined hidden or internal weak
symbols
Product: binutils
Version: 2.29 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: ma...@linux-mips.org
Reporter: ma...@linux-mips.org
Target Milestone: ---
Target: mips*-*-linux-gnu
Created attachment 9986
--> https://sourceware.org/bugzilla/attachment.cgi?id=9986&action=edit
WIP bug fix
This has been discovered in the course of PR ld/21334 investigation.
We have an issue in the MIPS backend, with handling undefined hidden
and internal weak symbols. References to such symbols are supposed to
resolve to 0 according to the ELF gABI[1]:
"Unresolved weak symbols have a zero value."
and the 64-bit MIPS psABI[2]:
"If a symbol with one of these [hidden or internal] attributes has no
definition within the executable/DSO being linked, then it must be
resolved to allocated space if common, resolved to zero if weak, or an
error reported otherwise."
however if a GOT relocation is used, then a local GOT entry is created
and used to satisfy the reference. Such an entry is then (in DSO and
PIE binaries) subject to the usual load-time relocation, which means a
non-zero value will be returned if the base address is non-zero. This
will defeat the usual run-time sequence like:
void a (void) __attribute__ ((visibility ("hidden"), weak));
void
x (void)
{
if (a)
a ();
}
This can be reproduced with this simple code:
$ cat libtest.c
extern int a __attribute__ ((visibility ("hidden"), weak));
int *
x (void)
{
return &a;
}
$ cat test.c
#include
int *x (void);
int
main (void)
{
printf ("a: %p\n", x ());
return 0;
}
$ gcc -shared -fPIC -o libtest.so libtest.c
$ gcc -o test test.c -Wl,-rpath,$(pwd) libtest.so
$ ./test
a: 0x77184000
$
What instead we should do I believe is create an *external* GOT entry
for the weak undefined symbol entered in the dynamic symbol table as
hidden or internal external absolute and having the value of 0. Having
a hidden or internal dynamic symbol is as from 22 June 2000 contrary to
the ELF gABI [3]:
"A hidden symbol contained in a relocatable object must be either
removed or converted to STB_LOCAL binding by the link-editor when the
relocatable object is included in an executable file or shared object."
"An internal symbol contained in a relocatable object must be either
removed or converted to STB_LOCAL binding by the link-editor when the
relocatable object is included in an executable file or shared object."
however so is having a non-zero undefined weak symbol. Furthermore the
gABI's requirement was introduced after the MIPS psABI first defined
hidden and internal symbol export classes, and with the psABI's
definition of DT_MIPS_HIDDEN_GOTIDX [4]:
"This member contains the index in the GOT of the first entry for a
hidden symbol. It is mandatory if there are hidden symbol entries."
indicating support for hidden symbols in the dynamic symbol table,
clearly without consideration what the implications for the MIPS psABI
of the gABI's requirement might be.
As from glibc commit b6084a958f20 ("Treat STV_HIDDEN and STV_INTERNAL
symbols as STB_LOCAL") the GNU dynamic loader handles hidden and internal
dynamic symbols correctly and I think producing a non-compliant binary
file that produces a result that is generally expected is more reasonable
than producing one that is neither compliant nor works as expected.
With this approach there is still an issue with the GNU dynamic loader
that does not tell regular and absolute symbols apart and relocates the
latter as if they were regular. This actually causes the linker solution
outlined here to make no change at all in run-time behaviour, but this is
not a regression and is clearly a bug in the dynamic loader which can be
addressed in a simple manner. A separate bug report will be filed to
handle that problem and referred here.
References:
[1] "System V Application Binary Interface - DRAFT - 19 October 2010",
The SCO Group, Section "Symbol Table",
[2] "64-bit ELF Object File Specification, Draft Version 2.5", MIPS
Technologies / Silicon Graphics Computer Systems, Order Number
007-4658-001, Section 2.5 "Symbol Table", p. 22,
[3] "System V Application Binary Interface - DRAFT - 22 June 2000",
The Santa Cruz Operation, Inc., Section "Symbol Table",
[4] same as [2], Section 3.3.1 "Dynamic Section", pp. 83, 84
--
You are receiving this mail because:
You are on the CC list for the bug.
__
[Bug ld/21334] [MIPS] Undefined hidden symbols cause assertion failure bfd/elfxx-mips.c:3860
https://sourceware.org/bugzilla/show_bug.cgi?id=21334 Maciej W. Rozycki changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #8 from Maciej W. Rozycki --- Incorrect dynamic relocation arrangement for undefined hidden and internal weak symbols now filed as PR ld/21375. -- 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/21375] MIPS: Non-zero run-time value produced for PIC references to undefined hidden or internal weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=21375 Maciej W. Rozycki changed: What|Removed |Added Status|NEW |ASSIGNED -- 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/21375] MIPS: Non-zero run-time value produced for PIC references to undefined hidden or internal weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=21375 Maciej W. Rozycki changed: What|Removed |Added Depends on||19818 Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=19818 [Bug 19818] Absolute (SHN_ABS) symbols incorrectly relocated by the base address -- 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/21375] MIPS: Non-zero run-time value produced for PIC references to undefined hidden or internal weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=21375 --- Comment #1 from Maciej W. Rozycki --- The corresponding GNU dynamic loader issue is preexisting PR 19818, now updated accordingly. -- 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/20402] ld.bfd for emits *_RELATIVE relocations against SHN_ABS symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=20402 Maciej W. Rozycki changed: What|Removed |Added CC||ma...@linux-mips.org -- 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/20402] ld.bfd for emits *_RELATIVE relocations against SHN_ABS symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=20402 --- Comment #6 from Maciej W. Rozycki --- See also PR 19818, for the corresponding GNU dynamic loader issue. -- 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/21086] static linking with --dynamic-list adds dynamic section and interpreter
https://sourceware.org/bugzilla/show_bug.cgi?id=21086 ma.jiang at zte dot com.cn changed: What|Removed |Added CC||ma.jiang at zte dot com.cn -- 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/21086] static linking with --dynamic-list adds dynamic section and interpreter
https://sourceware.org/bugzilla/show_bug.cgi?id=21086 ma.jiang at zte dot com.cn changed: What|Removed |Added CC||ma.jiang at zte dot com.cn -- 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/21086] static linking with --dynamic-list adds dynamic section and interpreter
https://sourceware.org/bugzilla/show_bug.cgi?id=21086 ma.jiang at zte dot com.cn changed: What|Removed |Added CC||ma.jiang at zte dot com.cn -- 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/21086] static linking with --dynamic-list adds dynamic section and interpreter
https://sourceware.org/bugzilla/show_bug.cgi?id=21086 ma.jiang at zte dot com.cn changed: What|Removed |Added CC||ma.jiang at zte dot com.cn -- 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/21086] static linking with --dynamic-list adds dynamic section and interpreter
https://sourceware.org/bugzilla/show_bug.cgi?id=21086 --- Comment #5 from ma.jiang at zte dot com.cn --- Hi guys, I encoutered this bug when trying to compile a static-linked perf. In my option, there were two serious problem here. First of all, ld should never create a broken executable silently. If "-static" is conflicted with any other option, ld should abort and print information about the conflict. Secondly, "--dynamic-list" should be documented more clearly and directly. "Specify the name of a dynamic list file to the linker. This is typically used when creating shared libraries to specify a list of global symbols whose references shouldn't be bound to the definition within the shared library, or creating dynamically linked executables to specify a list of symbols which should be added to the symbol table in the executable." This paragraph（listed above） in man pages is too obscure to tell users what the option really mean. I thinks we should clearly describe what the option do(and some symbol into dynamic symbol table?) first, and then tell users what are the typical scenarios. -- 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
