[Bug binutils/6449] objdump -S and DOS-style line-endings
--- Additional Comments From hjl dot tools at gmail dot com 2008-04-24 12:57 --- There are so many #ifndef O_BINARY #ifdef _O_BINARY #define O_BINARY _O_BINARY #define setmode _setmode #else #define O_BINARY 0 #endif #endif in binutils sources. It should go into sysdep.h. -- What|Removed |Added CC||hjl dot tools at gmail dot ||com http://sourceware.org/bugzilla/show_bug.cgi?id=6449 --- 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 hjl dot tools at gmail dot com 2008-04-24 13:00 --- Why does it limit to PIE? If a symbol in shared library is resolved locally, will we run into the same problem? -- What|Removed |Added CC||hjl dot tools at gmail 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/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 hjl dot tools at gmail dot com 2008-04-24 13:25 --- (In reply to comment #4) > 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. > Can you add those comments in your patch? Also please add a testcase for each change. Your testcase only shows R_X86_64_TPOFF32 is affected. But your proposed change affects many other TLS relocations. Are they really necessary? -- 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 hjl dot tools at gmail dot com 2008-04-24
13:31 ---
Will this patch
--- elf64-x86-64.c.pie 2008-04-24 06:05:36.0 -0700
+++ elf64-x86-64.c 2008-04-24 06:29:08.0 -0700
@@ -1050,7 +1050,7 @@ elf64_x86_64_check_relocs (bfd *abfd, st
goto create_got;
case R_X86_64_TPOFF32:
- if (info->shared)
+ if (!info->executable)
{
(*_bfd_error_handler)
(_("%B: relocation %s against `%s' can not be used when making a
shared object; recompile with -fPIC"),
@@ -3211,7 +3211,7 @@ elf64_x86_64_relocate_section (bfd *outp
break;
case R_X86_64_TPOFF32:
- BFD_ASSERT (! info->shared);
+ BFD_ASSERT (info->executable);
relocation = tpoff (info, relocation);
break;
be enough for x86-64?
--
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 hjl dot tools at gmail dot com 2008-04-24 13:56 --- Subject: Re: -pie issues with TLS relocations On Thu, Apr 24, 2008 at 6:46 AM, jakub at redhat dot com <[EMAIL PROTECTED]> wrote: > > --- 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. > Please add testcases to your patch to make sure that only necessary changes are included. -- 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
no support for undefined weak 16-bit coff symbols
I configured binutils 2.18 for z80-unknown-coff and tried this:
$ cat a.s
.weak foo
call foo
$ objdir-z80/gas/as-new -o a.o a.s
$ objdir-z80/binutils/objdump -tdr a.o
a.o: file format coff-z80
SYMBOL TABLE:
[ 0](sec -2)(fl 0x00)(ty 0)(scl 103) (nx 1) 0x fake
File
[ 2](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x .text
AUX scnlen 0x3 nreloc 1 nlnno 0
[ 4](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x .data
AUX scnlen 0x0 nreloc 0 nlnno 0
[ 6](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x .bss
AUX scnlen 0x0 nreloc 0 nlnno 0
[ 8](sec 0)(fl 0x00)(ty 0)(scl 127) (nx 0) 0x foo
Disassembly of section .text:
<.text>:
0: cd 00 00call 0x
1: r_imm16 foo
$ objdir-z80/ld/ld-new -o a a.o
a.o:fake:(.text+0x1): undefined reference to `foo'
It looks like bfd_coff_reloc16_get_value() doesn't know about
undefined weak symbols. This patch fixes the problem for me:
--- ../binutils-2.18/bfd/reloc16.c 2007-08-06 20:59:40.0 +0100
+++ bfd/reloc16.c 2008-04-24 11:10:17.0 +0100
@@ -76,6 +76,10 @@
else if (h != (struct bfd_link_hash_entry *) NULL
&& h->type == bfd_link_hash_common)
value = h->u.c.size;
+ else if (h != (struct bfd_link_hash_entry *) NULL
+ && h->type == bfd_link_hash_undefweak)
+ /* This is a GNU extension. */
+ value = 0;
else
{
if (!((*link_info->callbacks->undefined_symbol)
Thanks,
Jay.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6449] objdump -S and DOS-style line-endings
-- What|Removed |Added CC||eric dot weddington at atmel ||dot com http://sourceware.org/bugzilla/show_bug.cgi?id=6449 --- 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
