This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: bfd_sizeof_headers
On Tue, 20 Jun 2006, Alan Modra wrote:
> * emultempl/mmo.em: Correct comment. Include elf-bfd.h and
> source elf-generic.em.
> (mmo_finish): Call gld${EMULATION_NAME}_map_segments.
That doesn't seem right. mmo.em isn't *intended* to emit ELF
output. Though I see no failures with your change.
Weirder, when I revert it, I get:
FAIL: ld-mmix/bpo-22
That's just an insanity test-case:
# This weird combination of format and emulation options caused hiccups in
# the reloc accounting machinery.
(Referring to "-m mmo --oformat elf64-mmix", akin of
"-m i386aout --oformat elf32-i386" or something like that.
Oh yuck. Why oh why is that allowed.)
I'm not sure what to expect for that case, except for no SEGV.
It does get a new warning, which is the cause for the FAIL:
./ld-new: tmpdir/dump: warning: allocated section `.text' not in segment
Other than that, the output seems by manual inspection to match
the test. Was that test the reason?
I don't see the same change for all usually-non-ELF emulations
e.g. a.out targets; can that be construed as due to lack of
test-cases for the corresponding combination?
I don't like mixing up mmo with ELF stuff like that, but as long
as ld can be forced to take that route, I'm not sure what to do.
Maybe a simplistic local map_segments function in mmo.em, like
for place_orphan. But then, re-using elf-generic.em seems
simple enough, so let's keep it, but adding some warning-signs,
hopefully removing some sources for confusion.
> Index: ld/emultempl/mmo.em
> ===================================================================
> RCS file: /cvs/src/src/ld/emultempl/mmo.em,v
> retrieving revision 1.17
> diff -u -p -w -r1.17 mmo.em
> --- ld/emultempl/mmo.em 17 Nov 2005 00:10:05 -0000 1.17
> +++ ld/emultempl/mmo.em 20 Jun 2006 00:53:55 -0000
> @@ -18,16 +18,18 @@
> # Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, USA.
> #
>
> -# This file is sourced from elf32.em and mmo.em, used to define
> -# linker MMIX-specifics common to ELF and MMO.
> +# This file is sourced from generic.em
That sentence you changed was surely confusing; it was wrongly
copied from mmix-elfnmmo.em.
Here's what I committed. Did I mix anything up?
* emultempl/mmo.em: Improve comments. Explain why there's
ELF-stuff here.
Index: emultempl/mmo.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/mmo.em,v
retrieving revision 1.18
diff -p -u -r1.18 mmo.em
--- emultempl/mmo.em 20 Jun 2006 02:22:14 -0000 1.18
+++ emultempl/mmo.em 21 Jun 2006 02:42:44 -0000
@@ -1,5 +1,5 @@
# This shell script emits a C file. -*- C -*-
-# Copyright 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
+# Copyright 2001, 2002, 2003, 2004, 2006 Free Software Foundation, Inc.
#
# This file is part of GLD, the Gnu Linker.
#
@@ -18,14 +18,20 @@
# Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, USA.
#
-# This file is sourced from generic.em
+# This file is sourced from generic.em.
cat >>e${EMULATION_NAME}.c <<EOF
-/* Need to have this define before mmix-elfnmmo, which includes
- needrelax.em which uses this name for the before_allocation function,
- normally defined in elf32.em. */
+/* Need to have this macro defined before mmix-elfnmmo, which uses the
+ name for the before_allocation function, defined in ldemul.c (for
+ the mmo "emulation") or in elf32.em (for the elf64mmix
+ "emulation"). */
#define gldmmo_before_allocation before_allocation_default
+/* We include this header *not* because we expect to handle ELF here
+ but because we re-use the map_segments function in elf-generic.em,
+ a file which is rightly somewhat ELF-centric. But this is only to
+ get a weird testcase right; ld-mmix/bpo-22, forcing ELF to be
+ output from the mmo emulation: -m mmo --oformat elf64-mmix! */
#include "elf-bfd.h"
EOF
brgds, H-P