* elfNN-foo-fbsd hackery?
@ 2002-10-14 18:27 Richard Henderson
2002-10-14 21:28 ` Alan Modra
0 siblings, 1 reply; 4+ messages in thread
From: Richard Henderson @ 2002-10-14 18:27 UTC (permalink / raw)
To: binutils
What's up with the FreeBSD targets including other source
files and gratuitously bloating and already hefty library?
In particular, it seems like the following would work, with
similar for the i386 target.
Thoughts?
r~
* Makefile.am (BFD64_BACKENDS): Remove elf64-alpha-fbsd.lo
(BFD64_BACKENDS_CFILES): Remove elf64-alpha-fbsd.c
* elf64-alpha-fbsd.c: Remove file. Move code ...
* elf64-alpha.c: ... here.
Index: Makefile.am
===================================================================
RCS file: /cvs/src/src/bfd/Makefile.am,v
retrieving revision 1.105
diff -c -p -d -u -r1.105 Makefile.am
--- Makefile.am 14 Oct 2002 12:06:03 -0000 1.105
+++ Makefile.am 15 Oct 2002 01:23:05 -0000
@@ -491,7 +491,6 @@ BFD64_BACKENDS = \
efi-app-ia64.lo \
elf64-x86-64.lo \
elf64-alpha.lo \
- elf64-alpha-fbsd.lo \
elf64-hppa.lo \
elf64-ia64.lo \
elf64-gen.lo \
@@ -519,7 +518,6 @@ BFD64_BACKENDS_CFILES = \
efi-app-ia64.c \
elf64-x86-64.c \
elf64-alpha.c \
- elf64-alpha-fbsd.c \
elf64-hppa.c \
elf64-gen.c \
elfn32-mips.c \
@@ -1543,13 +1541,6 @@ elf64-alpha.lo: elf64-alpha.c $(INCDIR)/
$(INCDIR)/coff/sym.h $(INCDIR)/coff/symconst.h $(INCDIR)/coff/ecoff.h \
$(INCDIR)/coff/alpha.h $(INCDIR)/aout/ar.h libcoff.h \
libecoff.h ecoffswap.h elf64-target.h
-elf64-alpha-fbsd.lo: elf64-alpha-fbsd.c $(INCDIR)/filenames.h \
- elf-bfd.h $(INCDIR)/elf/common.h $(INCDIR)/elf/internal.h \
- $(INCDIR)/elf/external.h $(INCDIR)/bfdlink.h elf64-alpha.c \
- $(INCDIR)/elf/alpha.h $(INCDIR)/elf/reloc-macros.h \
- $(INCDIR)/coff/internal.h $(INCDIR)/coff/sym.h $(INCDIR)/coff/symconst.h \
- $(INCDIR)/coff/ecoff.h $(INCDIR)/coff/alpha.h $(INCDIR)/aout/ar.h \
- libcoff.h libecoff.h ecoffswap.h elf64-target.h
elf64-hppa.lo: elf64-hppa.c $(INCDIR)/alloca-conf.h \
$(INCDIR)/filenames.h elf-bfd.h $(INCDIR)/elf/common.h \
$(INCDIR)/elf/internal.h $(INCDIR)/elf/external.h $(INCDIR)/bfdlink.h \
Index: elf64-alpha.c
===================================================================
RCS file: /cvs/src/src/bfd/elf64-alpha.c,v
retrieving revision 1.83
diff -c -p -d -u -r1.83 elf64-alpha.c
--- elf64-alpha.c 15 Oct 2002 01:07:52 -0000 1.83
+++ elf64-alpha.c 15 Oct 2002 01:23:06 -0000
@@ -5510,13 +5510,11 @@ static const struct elf_size_info alpha_
NULL
};
-#ifndef ELF_ARCH
#define TARGET_LITTLE_SYM bfd_elf64_alpha_vec
#define TARGET_LITTLE_NAME "elf64-alpha"
#define ELF_ARCH bfd_arch_alpha
#define ELF_MACHINE_CODE EM_ALPHA
#define ELF_MAXPAGESIZE 0x10000
-#endif /* ELF_ARCH */
#define bfd_elf64_bfd_link_hash_table_create \
elf64_alpha_bfd_link_hash_table_create
@@ -5580,5 +5578,41 @@ static const struct elf_size_info alpha_
#define elf_backend_want_plt_sym 1
#define elf_backend_got_header_size 0
#define elf_backend_plt_header_size PLT_HEADER_SIZE
+
+#include "elf64-target.h"
+\f
+/* FreeBSD support. */
+
+#undef TARGET_LITTLE_SYM
+#define TARGET_LITTLE_SYM bfd_elf64_alpha_freebsd_vec
+#undef TARGET_LITTLE_NAME
+#define TARGET_LITTLE_NAME "elf64-alpha-freebsd"
+
+/* The kernel recognizes executables as valid only if they carry a
+ "FreeBSD" label in the ELF header. So we put this label on all
+ executables and (for simplicity) also all other object files. */
+
+static void elf64_alpha_fbsd_post_process_headers
+ PARAMS ((bfd *, struct bfd_link_info *));
+
+static void
+elf64_alpha_fbsd_post_process_headers (abfd, link_info)
+ bfd * abfd;
+ struct bfd_link_info * link_info ATTRIBUTE_UNUSED;
+{
+ Elf_Internal_Ehdr * i_ehdrp; /* ELF file header, internal form. */
+
+ i_ehdrp = elf_elfheader (abfd);
+
+ /* Put an ABI label supported by FreeBSD >= 4.1. */
+ i_ehdrp->e_ident[EI_OSABI] = ELFOSABI_FREEBSD;
+#ifdef OLD_FREEBSD_ABI_LABEL
+ /* The ABI label supported by FreeBSD <= 4.0 is quite nonstandard. */
+ memcpy (&i_ehdrp->e_ident[EI_ABIVERSION], "FreeBSD", 8);
+#endif
+}
+
+#define elf_backend_post_process_headers \
+ elf64_alpha_fbsd_post_process_headers
#include "elf64-target.h"
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: elfNN-foo-fbsd hackery?
2002-10-14 18:27 elfNN-foo-fbsd hackery? Richard Henderson
@ 2002-10-14 21:28 ` Alan Modra
2002-10-15 9:41 ` Richard Henderson
0 siblings, 1 reply; 4+ messages in thread
From: Alan Modra @ 2002-10-14 21:28 UTC (permalink / raw)
To: Richard Henderson; +Cc: binutils
On Mon, Oct 14, 2002 at 06:27:21PM -0700, Richard Henderson wrote:
> * Makefile.am (BFD64_BACKENDS): Remove elf64-alpha-fbsd.lo
> (BFD64_BACKENDS_CFILES): Remove elf64-alpha-fbsd.c
> * elf64-alpha-fbsd.c: Remove file. Move code ...
> * elf64-alpha.c: ... here.
Exactly what I intended doing when I found a spare moment. x86 has
qnx to contend with as well.
Of course, the bloat only happens when you enable multiple bfd
targets, and I have a nagging suspicion that certain operations
(*) might bomb with "File format is ambiguous" if you provide
two bfd vectors.
*) Like "objcopy -O binary blah.o blah.bin". Hmm, here's an
example:
$ .../all/binutils/objcopy -O binary powerpc-linux/libiberty/hex.o blah.bin
all/binutils/objcopy: powerpc-linux/libiberty/hex.o: File format not recognized
$ .../x86/binutils/objcopy -O binary powerpc-linux/libiberty/hex.o blah.bin
$
The "all" objcopy is --target=i686-linux --enable-targets=all,
while the "x86" objcopy is --target=i686-linux
--enable-targets=i686-linuxaout,i686-coff,hppa-linux,powerpc-linux
The first case fails because we're reading a non-default object which
matches multiple powerpc targets, while the second case works because
we only have one matching target. Not that I think this is
particularly worrying. I'm just illustrating the point that providing
two targets may not be desirable in all situations.
Gack, and that's a terrible error message from objcopy. Fixing..
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: elfNN-foo-fbsd hackery?
2002-10-14 21:28 ` Alan Modra
@ 2002-10-15 9:41 ` Richard Henderson
2002-10-15 16:46 ` Alan Modra
0 siblings, 1 reply; 4+ messages in thread
From: Richard Henderson @ 2002-10-15 9:41 UTC (permalink / raw)
To: binutils
On Tue, Oct 15, 2002 at 01:58:45PM +0930, Alan Modra wrote:
> Exactly what I intended doing when I found a spare moment. x86 has
> qnx to contend with as well.
Oh good. I'll go ahead and commit the alpha patch then.
> Of course, the bloat only happens when you enable multiple bfd
> targets, and I have a nagging suspicion that certain operations
> (*) might bomb with "File format is ambiguous" if you provide
> two bfd vectors.
The vector isn't "provided" until it's present in _bfd_target_vector,
and that set doesn't change with or without elf64-alpha-fsd.c. So
this patch doesn't change that behaviour at all.
r~
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: elfNN-foo-fbsd hackery?
2002-10-15 9:41 ` Richard Henderson
@ 2002-10-15 16:46 ` Alan Modra
0 siblings, 0 replies; 4+ messages in thread
From: Alan Modra @ 2002-10-15 16:46 UTC (permalink / raw)
To: binutils
On Tue, Oct 15, 2002 at 09:41:34AM -0700, Richard Henderson wrote:
> The vector isn't "provided" until it's present in _bfd_target_vector,
Ah, yes. Didn't think of that.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-10-15 23:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-14 18:27 elfNN-foo-fbsd hackery? Richard Henderson
2002-10-14 21:28 ` Alan Modra
2002-10-15 9:41 ` Richard Henderson
2002-10-15 16:46 ` Alan Modra
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).