This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PATCH: PR ld/5913: IA64 linker crashes on supported relocations
- From: Jim Wilson <wilson at tuliptree dot org>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: 2008年3月12日 22:16:37 -0700
- Subject: Re: PATCH: PR ld/5913: IA64 linker crashes on supported relocations
- References: <6dc9ffc80803111305x6854b764pca9cbbbcbb51a956@mail.gmail.com>
H.J. Lu wrote:
IA64 Linker crashes on bad input in
It looks like every port with TLS support has this problem, except maybe
the FRV port. A bit more than half of them have
/* If tls_sec is NULL, we should have signalled an error already. */
if (elf_hash_table (info)->tls_sec == NULL)
return 0;
When I tried pasting that into the IA-64 port, I got no error at all. A
bit less than half have
BFD_ASSERT (elf_hash_table (info)->tls_sec != NULL);
like the IA-64 port. The elf32-ppc.c port has no checks for a NULL
tls_sec. And the FRV port does this differently, it has this code:
if (! elf_hash_table (info)->tls_sec)
{
(*info->callbacks->undefined_symbol)
(info, "TLS section", elf_hash_table (info)->dynobj,
frvfdpic_got_section (info), entry->tlsoff_entry, TRUE);
return FALSE;
}
So it looks like the FRV port is the only one that currently handles
this correctly.
Should we be trying to fix every target here, instead of just the IA-64
port?
I tried to create my own testcase for x86 to see what happens there, but
neither the assembler nor objcopy will let me create a broken .o file,
which make me wonder how you created your testcase. If this situation
is very hard to get, maybe we don't need to worry about fixing other
targets.
As for the patch, it seems reasonable. We could maybe eliminate the
code duplication by making elfNN_ia64_tprel_base and
elfNN_ia64_dtprel_base into macros. Maybe the error message should say
something about the missing tls section like the FRV port does? The
error message says that the relocation is unsupported, but doesn't give
any clue as to why.
Jim