* Linking against ET_EXEC objects
@ 2004-10-13 14:28 Jakub Jelinek
2004-10-14 5:51 ` Ian Lance Taylor
0 siblings, 1 reply; 2+ messages in thread
From: Jakub Jelinek @ 2004-10-13 14:28 UTC (permalink / raw)
To: binutils
Hi!
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135498
is a linker assert failure/segfault on PPC64 when building
klibc.
It turns out this is because klibc's libc.so is ET_EXEC object
which has no relocations, .dynamic sections etc.
Is linking against ET_EXEC objects something that we should
support at all?
If no, we should issue an error message early and bail out.
If yes, I'm afraid we need to audit the abfd->flags & DYNAMIC
checks all around the code and see what are relevant also
to ET_EXEC (in bfd's speak abfd->flags & EXEC_P) input files.
E.g. in elf_link_add_object_symbols in that case would probably
need:
- if ((abfd->flags & DYNAMIC) == 0)
+ if ((abfd->flags & (DYNAMIC | EXEC_P)) == 0)
dynamic = FALSE;
else
{
dynamic = TRUE;
so that abfd->sections is NULL etc., but when I did this,
ld failed assertions elsewhere.
Jakub
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Linking against ET_EXEC objects
2004-10-13 14:28 Linking against ET_EXEC objects Jakub Jelinek
@ 2004-10-14 5:51 ` Ian Lance Taylor
0 siblings, 0 replies; 2+ messages in thread
From: Ian Lance Taylor @ 2004-10-14 5:51 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: binutils
Jakub Jelinek <jakub@redhat.com> writes:
> Is linking against ET_EXEC objects something that we should
> support at all?
I don't think so.
Ian
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-10-14 5:51 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-13 14:28 Linking against ET_EXEC objects Jakub Jelinek
2004-10-14 5:51 ` Ian Lance Taylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).