Re: Not linking 32-bit and 64-bit objects

Re: Not linking 32-bit and 64-bit objects

[Martin Schwidefsky]

>> On Tue, Mar 12, 2002 at 11:40:18PM +1030, Alan Modra wrote:
>> : On Tue, Mar 12, 2002 at 01:20:38PM +0100, Andreas Jaeger wrote:
>> : >      * cpu-i386.c (i386_compatible): New.  Use it instead of
>> : >      bfd_default_compatible.
>> :
>> : OK.
>>
>> Alan, this seems to be a problem with ppc32 and ppc64 as well.
>> Do we need the same fix???
>
>Other 64-bit platforms might want this also.  Martin, what about S390?

Yes we want that for s390/s390x as well.

blue skies,
   Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com

Re: Not linking 32-bit and 64-bit objects

[Jakub Jelinek]

On Tue, Mar 12, 2002 at 03:48:18PM +0100, Martin Schwidefsky wrote:
> 
> >> On Tue, Mar 12, 2002 at 11:40:18PM +1030, Alan Modra wrote:
> >> : On Tue, Mar 12, 2002 at 01:20:38PM +0100, Andreas Jaeger wrote:
> >> : >      * cpu-i386.c (i386_compatible): New.  Use it instead of
> >> : >      bfd_default_compatible.
> >> :
> >> : OK.
> >>
> >> Alan, this seems to be a problem with ppc32 and ppc64 as well.
> >> Do we need the same fix???
> >
> >Other 64-bit platforms might want this also.  Martin, what about S390?
> 
> Yes we want that for s390/s390x as well.

And for sparc/sparc64 too :).

	Jakub

Re: Not linking 32-bit and 64-bit objects

[Andreas Jaeger]

Jakub Jelinek <jakub@redhat.com> writes:

> On Tue, Mar 12, 2002 at 03:48:18PM +0100, Martin Schwidefsky wrote:
>> 
>> >> On Tue, Mar 12, 2002 at 11:40:18PM +1030, Alan Modra wrote:
>> >> : On Tue, Mar 12, 2002 at 01:20:38PM +0100, Andreas Jaeger wrote:
>> >> : >      * cpu-i386.c (i386_compatible): New.  Use it instead of
>> >> : >      bfd_default_compatible.
>> >> :
>> >> : OK.
>> >>
>> >> Alan, this seems to be a problem with ppc32 and ppc64 as well.
>> >> Do we need the same fix???
>> >
>> >Other 64-bit platforms might want this also.  Martin, what about S390?
>> 
>> Yes we want that for s390/s390x as well.
>
> And for sparc/sparc64 too :).

I copied the code from Sparc so you have it already for some time;-).
If it's not working, I would be really suprised.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Not linking 32-bit and 64-bit objects

[Jakub Jelinek]

On Tue, Mar 12, 2002 at 03:58:04PM +0100, Andreas Jaeger wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
> 
> > On Tue, Mar 12, 2002 at 03:48:18PM +0100, Martin Schwidefsky wrote:
> >> 
> >> >> On Tue, Mar 12, 2002 at 11:40:18PM +1030, Alan Modra wrote:
> >> >> : On Tue, Mar 12, 2002 at 01:20:38PM +0100, Andreas Jaeger wrote:
> >> >> : >      * cpu-i386.c (i386_compatible): New.  Use it instead of
> >> >> : >      bfd_default_compatible.
> >> >> :
> >> >> : OK.
> >> >>
> >> >> Alan, this seems to be a problem with ppc32 and ppc64 as well.
> >> >> Do we need the same fix???
> >> >
> >> >Other 64-bit platforms might want this also.  Martin, what about S390?
> >> 
> >> Yes we want that for s390/s390x as well.
> >
> > And for sparc/sparc64 too :).
> 
> I copied the code from Sparc so you have it already for some time;-).
> If it's not working, I would be really suprised.

It is not working properly.
It gives an error message, but then crashes anyway, e.g.:
$ gcc -m64 -c helloworld.c
$ gcc -o helloworld helloworld.o
/usr/bin/ld: warning: sparc:v9 architecture of input file `helloworld.o' is incompatible with sparc output
/usr/bin/ld: BFD 2.11.93.0.2 20020207 assertion fail elflink.h:2817
helloworld.o: In function `main':
helloworld.o(.text+0x0): relocation truncated to fit: R_SPARC_DISP8 *UND*
collect2: ld returned 1 exit status
$ gcc -c helloworld.c
$ gcc -m64 -o helloworld helloworld.o
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
/usr/bin/ld: warning: sparc architecture of input file `helloworld.o' is incompatible with sparc:v9 output
/usr/bin/ld: helloworld.o: invalid string offset 6841708 >= 47 for section `.strtab'

	Jakub

Re: Not linking 32-bit and 64-bit objects

[Andreas Jaeger]

Jakub Jelinek <jakub@redhat.com> writes:

> It is not working properly.
> It gives an error message, but then crashes anyway, e.g.:
> $ gcc -m64 -c helloworld.c
> $ gcc -o helloworld helloworld.o
> /usr/bin/ld: warning: sparc:v9 architecture of input file `helloworld.o' is incompatible with sparc output
> /usr/bin/ld: BFD 2.11.93.0.2 20020207 assertion fail elflink.h:2817
> helloworld.o: In function `main':
> helloworld.o(.text+0x0): relocation truncated to fit: R_SPARC_DISP8 *UND*
> collect2: ld returned 1 exit status
> $ gcc -c helloworld.c
> $ gcc -m64 -o helloworld helloworld.o
> collect2: ld terminated with signal 11 [Segmentation fault], core dumped
> /usr/bin/ld: warning: sparc architecture of input file `helloworld.o' is incompatible with sparc:v9 output
> /usr/bin/ld: helloworld.o: invalid string offset 6841708 >= 47 for section `.strtab'

:-(  That's really strange.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Not linking 32-bit and 64-bit objects

[Hans-Peter Nilsson]

On Tue, 12 Mar 2002, Jakub Jelinek wrote:
> On Tue, Mar 12, 2002 at 03:58:04PM +0100, Andreas Jaeger wrote:
> > I copied the code from Sparc so you have it already for some time;-).
> > If it's not working, I would be really suprised.
>
> It is not working properly.
> It gives an error message, but then crashes anyway, e.g.:

No, that's a warning message.

In the general case, you just get a warning with a
cpu-*:compatible check.  What happened for Andreas Jaeger's case
was for files searched for in the library path
(ldfile.c:ldfile_try_open_bfd).

If you put the object on the command-line (like crt1.o and your
case) it gets linked in as you noticed.  See
ldlang.c:lang_check.  Putting the test in
bfd_merge_private_bfd_data gives you an error (in the case of
library files, the file is ignored).

brgds, H-P

Re: Not linking 32-bit and 64-bit objects

[Hans-Peter Nilsson]

On Tue, 12 Mar 2002, Hans-Peter Nilsson wrote:

> Putting the test in
> bfd_merge_private_bfd_data gives you an error (in the case of
> library files, the file is ignored).

... provided you have a check in your elf_backend_object_p that
prevents mismatching elf-sizes from being recognized.

Or try getting that test generically in elfcode.h:elf_object_p.

brgds, H-P

Re: Not linking 32-bit and 64-bit objects

[Hans-Peter Nilsson]

On Tue, 12 Mar 2002, Hans-Peter Nilsson wrote:

 ...
> Or try getting that test generically in elfcode.h:elf_object_p.

Ignore that.  That test is already there, it seems.  Sorry.

brgds, H-P

Re: Not linking 32-bit and 64-bit objects

[Alan Modra]

On Tue, Mar 12, 2002 at 04:02:36PM +0100, Jakub Jelinek wrote:
> It is not working properly.
> It gives an error message, but then crashes anyway, e.g.:
> $ gcc -m64 -c helloworld.c
> $ gcc -o helloworld helloworld.o
> /usr/bin/ld: warning: sparc:v9 architecture of input file `helloworld.o' is incompatible with sparc output

It's a warning message, not an error..

> /usr/bin/ld: BFD 2.11.93.0.2 20020207 assertion fail elflink.h:2817
> helloworld.o: In function `main':
> helloworld.o(.text+0x0): relocation truncated to fit: R_SPARC_DISP8 *UND*
> collect2: ld returned 1 exit status
> $ gcc -c helloworld.c
> $ gcc -m64 -o helloworld helloworld.o
> collect2: ld terminated with signal 11 [Segmentation fault], core dumped
> /usr/bin/ld: warning: sparc architecture of input file `helloworld.o' is incompatible with sparc:v9 output
> /usr/bin/ld: helloworld.o: invalid string offset 6841708 >= 47 for section `.strtab'

Try it again with current sources.  You'll likely have warnings if
the foreign input file has relocs, but hopefully the core dump has
gone.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

re: Not linking 32-bit and 64-bit objects

[matthew green]

   
   It is not working properly.
   It gives an error message, but then crashes anyway, e.g.:
   $ gcc -m64 -c helloworld.c
   $ gcc -o helloworld helloworld.o
   /usr/bin/ld: warning: sparc:v9 architecture of input file `helloworld.o' is incompatible with sparc output
   /usr/bin/ld: BFD 2.11.93.0.2 20020207 assertion fail elflink.h:2817
   helloworld.o: In function `main':
   helloworld.o(.text+0x0): relocation truncated to fit: R_SPARC_DISP8 *UND*
   collect2: ld returned 1 exit status
   $ gcc -c helloworld.c
   $ gcc -m64 -o helloworld helloworld.o
   collect2: ld terminated with signal 11 [Segmentation fault], core dumped
   /usr/bin/ld: warning: sparc architecture of input file `helloworld.o' is incompatible with sparc:v9 output
   /usr/bin/ld: helloworld.o: invalid string offset 6841708 >= 47 for section `.strtab'


this works for an older release (2.11) on sparc for me... there was
bugs in the netbsd/sparc64 kernel makefiles that endedup attempting
to mix 32 & 64 bit objects, and ld failed gracefully..


.mrg.

Not linking 32-bit and 64-bit objects

[Andreas Jaeger]

If I try to link a 32-bit i386 object as 64-bit x86-64 object, it
should fail but I'd like to see a better error message.

Currently I get:
gee:~/tmp:[1]$ /opt/x86-64/bin/x86_64-unknown-linux-gcc k.o 
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
/opt/x86-64/lib/gcc-lib/x86_64-unknown-linux/3.1/../../../../x86_64-unknown-linux/bin/ld: BFD 2.12.90 20020312 assertion fail /cvs/binutils-ln/bfd/elflink.h:2649

I made the appended (not cleaned up) change and now I get:

gee:~/tmp:[1]$ /opt/x86-64/bin/x86_64-unknown-linux-gcc k.o 
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
/opt/x86-64/lib/gcc-lib/x86_64-unknown-linux/3.1/../../../../x86_64-unknown-linux/bin/ld: k.o: compiled for a 32 bit system and target is 64 bit
Bad value: failed to merge target specific data of file k.o
/opt/x86-64/lib/gcc-lib/x86_64-unknown-linux/3.1/../../../../x86_64-unknown-linux/bin/ld: BFD 2.12.90 20020312 assertion fail /cvs/binutils-ln/bfd/elflink.h:2649

This is better but I'm not happy, the linker should not abort but exit
cleanly.

So, my questions are:
- is this the right way to go (using merge_private_bfd_data)?
- how can I exit cleanly in this case?

Andreas

2002-03-12  Andreas Jaeger  <aj@suse.de>

	* elf64-x86-64.c (elf64_x86_64_merge_private_bfd_data): New.
	(bfd_elf64_bfd_merge_private_bfd_data): New.


============================================================
Index: bfd/elf64-x86-64.c
--- bfd/elf64-x86-64.c	2002/02/22 10:03:03	1.37
+++ bfd/elf64-x86-64.c	2002/03/12 10:59:09
@@ -2060,6 +2060,37 @@ elf64_x86_64_finish_dynamic_symbol (outp
   return true;
 }
 
+static boolean
+elf64_x86_64_merge_private_bfd_data (ibfd, obfd)
+     bfd *ibfd;
+     bfd *obfd;
+{
+  boolean error = false;
+
+  if (bfd_get_flavour (ibfd) != bfd_target_elf_flavour
+      || bfd_get_flavour (obfd) != bfd_target_elf_flavour)
+    return true;
+
+  if (bfd_get_mach (ibfd) != bfd_mach_x86_64
+      && bfd_get_mach (ibfd) != bfd_mach_x86_64_intel_syntax)
+    {
+      error = true;
+      (*_bfd_error_handler)
+	(_("%s: compiled for a 32 bit system and target is 64 bit"),
+	 bfd_archive_filename (ibfd));
+    }
+
+  if (error)
+    {
+      bfd_set_error (bfd_error_bad_value);
+      return false;
+    }
+
+  return true;
+}
+\f
+
+  
 /* Used to decide how to sort relocs in an optimal manner for the
    dynamic linker, before writing them out.  */
 
@@ -2231,6 +2262,7 @@ elf64_x86_64_finish_dynamic_sections (ou
 #define bfd_elf64_bfd_link_hash_table_create \
   elf64_x86_64_link_hash_table_create
 #define bfd_elf64_bfd_reloc_type_lookup	    elf64_x86_64_reloc_type_lookup
+#define bfd_elf64_bfd_merge_private_bfd_data elf64_x86_64_merge_private_bfd_data
 
 #define elf_backend_adjust_dynamic_symbol   elf64_x86_64_adjust_dynamic_symbol
 #define elf_backend_check_relocs	    elf64_x86_64_check_relocs

-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Not linking 32-bit and 64-bit objects

[Alan Modra]

On Tue, Mar 12, 2002 at 12:05:47PM +0100, Andreas Jaeger wrote:
> 
> If I try to link a 32-bit i386 object as 64-bit x86-64 object, it
> should fail but I'd like to see a better error message.

I think you're probably better off writing a replacement for
bfd_default_compatible in bfd/cpu-i386.c

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Not linking 32-bit and 64-bit objects

[Andreas Jaeger]

Alan Modra <amodra@bigpond.net.au> writes:

> On Tue, Mar 12, 2002 at 12:05:47PM +0100, Andreas Jaeger wrote:
>> 
>> If I try to link a 32-bit i386 object as 64-bit x86-64 object, it
>> should fail but I'd like to see a better error message.
>
> I think you're probably better off writing a replacement for
> bfd_default_compatible in bfd/cpu-i386.c

Thanks for the hint!

Now I get this:
gee:~/tmp:[1]$ /opt/x86-64/bin/x86_64-unknown-linux-gcc k.o 
/opt/x86-64/lib/gcc-lib/x86_64-unknown-linux/3.1/../../../../x86_64-unknown-linux/bin/ld: skipping incompatible /opt/x86-64/lib/gcc-lib/x86_64-unknown-linux/3.1/libgcc.a when searching for -lgcc
/opt/x86-64/lib/gcc-lib/x86_64-unknown-linux/3.1/../../../../x86_64-unknown-linux/bin/ld: cannot find -lgcc
collect2: ld returned 1 exit status

And I'm happy with it ;-)

Ok to commit?
Andreas

2002-03-12  Andreas Jaeger  <aj@suse.de>

	* cpu-i386.c (i386_compatible): New.  Use it instead of
	bfd_default_compatible.

Index: bfd/cpu-i386.c
===================================================================
RCS file: /cvs/src/src/bfd/cpu-i386.c,v
retrieving revision 1.6
diff -u -p -r1.6 cpu-i386.c
--- cpu-i386.c	2001/11/14 12:01:58	1.6
+++ cpu-i386.c	2002/03/12 12:19:56
@@ -1,5 +1,5 @@
 /* BFD support for the Intel 386 architecture.
-   Copyright 1992, 1994, 1995, 1996, 1998, 2000, 2001
+   Copyright 1992, 1994, 1995, 1996, 1998, 2000, 2001, 2002
    Free Software Foundation, Inc.
 
 This file is part of BFD, the Binary File Descriptor library.
@@ -22,6 +22,22 @@ Foundation, Inc., 59 Temple Place - Suit
 #include "sysdep.h"
 #include "libbfd.h"
 
+/* Don't mix 32 bit and 64 bit files.  */
+
+static const bfd_arch_info_type *i386_compatible
+  PARAMS ((const bfd_arch_info_type *, const bfd_arch_info_type *));
+
+static const bfd_arch_info_type *
+i386_compatible (a, b)
+     const bfd_arch_info_type *a;
+     const bfd_arch_info_type *b;
+{
+  if (a->bits_per_word != b->bits_per_word)
+    return NULL;
+
+  return bfd_default_compatible (a, b);
+}
+  
 const bfd_arch_info_type bfd_i386_arch_intel_syntax =
 {
   32,	/* 32 bits in a word */
@@ -33,7 +49,7 @@ const bfd_arch_info_type bfd_i386_arch_i
   "i386:intel",
   3,
   true,
-  bfd_default_compatible,
+  i386_compatible,
   bfd_default_scan ,
   0,
 };
@@ -48,7 +64,7 @@ const bfd_arch_info_type bfd_x86_64_arch
   "x86-64:intel",
   3,
   true,
-  bfd_default_compatible,
+  i386_compatible,
   bfd_default_scan ,
   &bfd_i386_arch_intel_syntax,
 };
@@ -63,7 +79,7 @@ static const bfd_arch_info_type i8086_ar
   "i8086",
   3,
   false,
-  bfd_default_compatible,
+  i386_compatible,
   bfd_default_scan ,
   &bfd_x86_64_arch_intel_syntax,
 };
@@ -79,7 +95,7 @@ const bfd_arch_info_type bfd_x86_64_arch
   "x86-64",
   3,
   true,
-  bfd_default_compatible,
+  i386_compatible,
   bfd_default_scan ,
   &i8086_arch,
 };
@@ -95,7 +111,7 @@ const bfd_arch_info_type bfd_i386_arch =
   "i386",
   3,
   true,
-  bfd_default_compatible,
+  i386_compatible,
   bfd_default_scan ,
   &bfd_x86_64_arch
 };

-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Not linking 32-bit and 64-bit objects

[Alan Modra]

On Tue, Mar 12, 2002 at 01:20:38PM +0100, Andreas Jaeger wrote:
> 	* cpu-i386.c (i386_compatible): New.  Use it instead of
> 	bfd_default_compatible.

OK.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Not linking 32-bit and 64-bit objects

[Peter Bergner]

On Tue, Mar 12, 2002 at 11:40:18PM +1030, Alan Modra wrote:
: On Tue, Mar 12, 2002 at 01:20:38PM +0100, Andreas Jaeger wrote:
: > 	* cpu-i386.c (i386_compatible): New.  Use it instead of
: > 	bfd_default_compatible.
: 
: OK.

Alan, this seems to be a problem with ppc32 and ppc64 as well.
Do we need the same fix???

Peter

--
Peter Bergner
Linux PPC64 Kernel & GLIBC Development
IBM Rochester, MN


begna% file foo.o
foo.o: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1, not stripped
begna% file bar.o 
bar.o: ELF 64-bit MSB relocatable, cisco 7500, version 1, not stripped
begna% /opt/ppc64-20020307/bin/powerpc64-linux-gcc -o foo foo.o bar.o 
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
/opt/ppc64-20020307/lib/gcc-lib/powerpc64-linux/3.0.5/../../../../powerpc64-linux/bin/ld: foo.o: invalid string offset 60 >= 31 for section `.strtab'
/opt/ppc64-20020307/lib/gcc-lib/powerpc64-linux/3.0.5/../../../../powerpc64-linux/bin/ld: foo.o: invalid string offset 6713199 >= 31 for section `.strtab'

Re: Not linking 32-bit and 64-bit objects

[Andreas Jaeger]

Peter Bergner <bergner@brule.borg.umn.edu> writes:

> On Tue, Mar 12, 2002 at 11:40:18PM +1030, Alan Modra wrote:
> : On Tue, Mar 12, 2002 at 01:20:38PM +0100, Andreas Jaeger wrote:
> : > 	* cpu-i386.c (i386_compatible): New.  Use it instead of
> : > 	bfd_default_compatible.
> : 
> : OK.
>
> Alan, this seems to be a problem with ppc32 and ppc64 as well.
> Do we need the same fix???

Other 64-bit platforms might want this also.  Martin, what about S390?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Not linking 32-bit and 64-bit objects

[David O'Brien]

On Tue, Mar 12, 2002 at 08:00:15AM -0600, Peter Bergner wrote:
> On Tue, Mar 12, 2002 at 11:40:18PM +1030, Alan Modra wrote:
> : On Tue, Mar 12, 2002 at 01:20:38PM +0100, Andreas Jaeger wrote:
> : > 	* cpu-i386.c (i386_compatible): New.  Use it instead of
> : > 	bfd_default_compatible.
> : 
> : OK.
> 
> Alan, this seems to be a problem with ppc32 and ppc64 as well.
> Do we need the same fix???

Same with sparc64 -- this just bit me hard on FreeBSD/sparc64.
 
-- 
-- David  (obrien@FreeBSD.org)

Re: Not linking 32-bit and 64-bit objects

[Daniel Jacobowitz]

On Tue, Mar 12, 2002 at 10:15:56PM +1030, Alan Modra wrote:
> On Tue, Mar 12, 2002 at 12:05:47PM +0100, Andreas Jaeger wrote:
> > 
> > If I try to link a 32-bit i386 object as 64-bit x86-64 object, it
> > should fail but I'd like to see a better error message.
> 
> I think you're probably better off writing a replacement for
> bfd_default_compatible in bfd/cpu-i386.c

Is there any architecture where linking together objects with a
different bits_per_word is really legal?  If not, adding it to
bfd_default_compatible seems like the logical step.  For instance, I
don't think MIPS-ELF32 and MIPS-ELF64 could really be linked together.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Not linking 32-bit and 64-bit objects

[Thiemo Seufer]

Daniel Jacobowitz wrote:
[snip]
> Is there any architecture where linking together objects with a
> different bits_per_word is really legal?

Some DSP's possibly allow this.

> If not, adding it to
> bfd_default_compatible seems like the logical step.  For instance, I
> don't think MIPS-ELF32 and MIPS-ELF64 could really be linked together.

FWIW, I can't see how this should work. BTW, the MIPS linker already
complains when checking the ELF header flags.


Thiemo

Re: Not linking 32-bit and 64-bit objects

[Alan Modra]

On Tue, Mar 12, 2002 at 11:32:15AM -0500, Daniel Jacobowitz wrote:
> On Tue, Mar 12, 2002 at 10:15:56PM +1030, Alan Modra wrote:
> > On Tue, Mar 12, 2002 at 12:05:47PM +0100, Andreas Jaeger wrote:
> > > 
> > > If I try to link a 32-bit i386 object as 64-bit x86-64 object, it
> > > should fail but I'd like to see a better error message.
> > 
> > I think you're probably better off writing a replacement for
> > bfd_default_compatible in bfd/cpu-i386.c
> 
> Is there any architecture where linking together objects with a
> different bits_per_word is really legal?

Depends on what you mean by "legal".  From a BFD viewpoint, where we
try to link anything with everything, the real problem is that BFD
currently fails when attempting to process relocs for the foreign
word size.  The ELF linker should treat these files similarly to
non-ELF files.  ie. The test at elflink.h:5331

	  if (p->type == bfd_indirect_link_order
	      && (bfd_get_flavour (p->u.indirect.section->owner)
		  == bfd_target_elf_flavour))

needs to test for wordsize too.

From a user viewpoint, I'm not sure of the right answer.  I'd guess
that in most cases where this situation arises, it's because the
user inadvertently linked against the wrong library.  However, if
we prohibit this, someone is sure to complain that his "simple"
object with the wrong word-size won't link.  Maybe I was a little
hasty telling Andreas to change cpu-i386.c, but let's not revert
it just yet. :)

Ian, can I bother you for an opinion?

>  If not, adding it to
> bfd_default_compatible seems like the logical step.  For instance, I
> don't think MIPS-ELF32 and MIPS-ELF64 could really be linked together.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Not linking 32-bit and 64-bit objects

[Ian Lance Taylor]

Alan Modra <amodra@bigpond.net.au> writes:

> Depends on what you mean by "legal".  From a BFD viewpoint, where we
> try to link anything with everything, the real problem is that BFD
> currently fails when attempting to process relocs for the foreign
> word size.  The ELF linker should treat these files similarly to
> non-ELF files.  ie. The test at elflink.h:5331
> 
> 	  if (p->type == bfd_indirect_link_order
> 	      && (bfd_get_flavour (p->u.indirect.section->owner)
> 		  == bfd_target_elf_flavour))
> 
> needs to test for wordsize too.

That makes sense to me.  The code in elf_link_input_bfd clearly
assumes that it is reading ELF information which is the same size as
the current backend.

> From a user viewpoint, I'm not sure of the right answer.  I'd guess
> that in most cases where this situation arises, it's because the
> user inadvertently linked against the wrong library.  However, if
> we prohibit this, someone is sure to complain that his "simple"
> object with the wrong word-size won't link.  Maybe I was a little
> hasty telling Andreas to change cpu-i386.c, but let's not revert
> it just yet. :)

The advantage of checking for problems in bfd_arch_get_compatible or
bfd_merge_private_bfd_data is that it permits the user to use the
--no-warn-mismatch option.  Then the default is to give a warning
(bfd_arch_get_compatible) or error (bfd_merge_private_bfd_data) while
still permitting the (sophisticated) user to force the link to
proceed.

Ian

Re: Not linking 32-bit and 64-bit objects

[Alan Modra]

This should stop the linker trying to do silly things with incompatible
relocs.

bfd/ChangeLog
	* elflink.h (elf_bfd_final_link): Only call elf_link_input_bfd
	when word size of input matches output word size.

ld/ChangeLog
	* ldlang.c (lang_check): Do relocatable link checks first, so that
	warn_mismatch can't override.  Check compatible and word size too.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Index: bfd/elflink.h
===================================================================
RCS file: /cvs/src/src/bfd/elflink.h,v
retrieving revision 1.145
diff -u -p -r1.145 elflink.h
--- elflink.h	2002/03/05 05:18:41	1.145
+++ elflink.h	2002/03/13 02:33:29
@@ -5320,10 +5320,11 @@ elf_bfd_final_link (abfd, info)
       for (p = o->link_order_head; p != NULL; p = p->next)
 	{
 	  if (p->type == bfd_indirect_link_order
-	      && (bfd_get_flavour (p->u.indirect.section->owner)
-		  == bfd_target_elf_flavour))
+	      && (bfd_get_flavour ((sub = p->u.indirect.section->owner))
+		  == bfd_target_elf_flavour)
+	      && (sub->arch_info->bits_per_word
+		  == abfd->arch_info->bits_per_word))
 	    {
-	      sub = p->u.indirect.section->owner;
 	      if (! sub->output_has_begun)
 		{
 		  if (! elf_link_input_bfd (&finfo, sub))
Index: ld/ldlang.c
===================================================================
RCS file: /cvs/src/src/ld/ldlang.c,v
retrieving revision 1.75
diff -u -p -r1.75 ldlang.c
--- ldlang.c	2002/02/15 02:11:05	1.75
+++ ldlang.c	2002/03/13 02:50:43
@@ -3569,8 +3569,27 @@ lang_check ()
        file = file->input_statement.next)
     {
       input_bfd = file->input_statement.the_bfd;
-      compatible = bfd_arch_get_compatible (input_bfd,
-					    output_bfd);
+      compatible = bfd_arch_get_compatible (input_bfd, output_bfd);
+
+      /* In general it is not possible to perform a relocatable
+	 link between differing object formats when the input
+	 file has relocations, because the relocations in the
+	 input format may not have equivalent representations in
+	 the output format (and besides BFD does not translate
+	 relocs for other link purposes than a final link).  */
+      if (link_info.relocateable
+	  && (compatible == NULL
+	      || bfd_get_flavour (input_bfd) != bfd_get_flavour (output_bfd)
+	      || (input_bfd->arch_info->bits_per_word
+		  != output_bfd->arch_info->bits_per_word))
+	  && (bfd_get_file_flags (input_bfd) & HAS_RELOC) != 0)
+	{
+	  einfo (_("%P%F: Relocatable linking with relocations from format %s (%B) to format %s (%B) is not supported\n"),
+		 bfd_get_target (input_bfd), input_bfd,
+		 bfd_get_target (output_bfd), output_bfd);
+	  /* einfo with %F exits.  */
+	}
+
       if (compatible == NULL)
 	{
 	  if (command_line.warn_mismatch)
@@ -3578,18 +3597,6 @@ lang_check ()
 		   bfd_printable_name (input_bfd), input_bfd,
 		   bfd_printable_name (output_bfd));
 	}
-      else if (link_info.relocateable
-	       /* In general it is not possible to perform a relocatable
-		  link between differing object formats when the input
-		  file has relocations, because the relocations in the
-		  input format may not have equivalent representations in
-		  the output format (and besides BFD does not translate
-		  relocs for other link purposes than a final link).  */
-	       && bfd_get_flavour (input_bfd) != bfd_get_flavour (output_bfd)
-	       && (bfd_get_file_flags (input_bfd) & HAS_RELOC) != 0)
-	einfo (_("%P%F: Relocatable linking with relocations from format %s (%B) to format %s (%B) is not supported\n"),
-	       bfd_get_target (input_bfd), input_bfd,
-	       bfd_get_target (output_bfd), output_bfd);
       else if (bfd_count_sections (input_bfd))
 	{
 	  /* If the input bfd has no contents, it shouldn't set the

Re: Not linking 32-bit and 64-bit objects

[Alan Modra]

I think we may as well make bfd_default_compatible test for matching
word size.  This change will affect hppa, powerpc, mips, s390 and sh.
sparc, and x86 (as of a few hours ago) already checked for matching
word size.

cpu-i370.c:i370_compatible behaved more or less the same as
bfd_default_compatible, so I zapped it.  cpu-h8300.c:compatible
needed to check the arch to be safe.

bfd/ChangeLog
	* archures.c (bfd_default_compatible): Test bits_per_word.
	* cpu-i386.c (i386_compatible): Remove.  Replace occurrences with
	bfd_default_compatible.
	* cpu-i370.c (i370_compatible): Likewise.
	* cpu-sparc.c (sparc_compatible): Likewise.
	* cpu-h8300.c (compatible): Test in->arch == out->arch.

Index: bfd/archures.c
===================================================================
RCS file: /cvs/src/src/bfd/archures.c,v
retrieving revision 1.46
diff -u -p -r1.46 archures.c
--- archures.c	2002/02/19 18:22:16	1.46
+++ archures.c	2002/03/13 06:45:55
@@ -722,6 +722,9 @@ bfd_default_compatible (a, b)
   if (a->arch != b->arch)
     return NULL;
 
+  if (a->bits_per_word != b->bits_per_word)
+    return NULL;
+
   if (a->mach > b->mach)
     return a;
 
Index: bfd/cpu-h8300.c
===================================================================
RCS file: /cvs/src/src/bfd/cpu-h8300.c,v
retrieving revision 1.6
diff -u -p -r1.6 cpu-h8300.c
--- cpu-h8300.c	2001/09/18 09:57:22	1.6
+++ cpu-h8300.c	2002/03/13 06:45:55
@@ -91,7 +91,7 @@ compatible (in, out)
      const bfd_arch_info_type *out;
 {
   /* It's really not a good idea to mix and match modes.  */
-  if (in->mach != out->mach)
+  if (in->arch != out->arch || in->mach != out->mach)
     return 0;
   else
     return in;
Index: bfd/cpu-i370.c
===================================================================
RCS file: /cvs/src/src/bfd/cpu-i370.c,v
retrieving revision 1.3
diff -u -p -r1.3 cpu-i370.c
--- cpu-i370.c	2001/03/08 21:03:58	1.3
+++ cpu-i370.c	2002/03/13 06:45:55
@@ -24,27 +24,6 @@ Foundation, Inc., 59 Temple Place - Suit
 #include "sysdep.h"
 #include "libbfd.h"
 
-/* The common i360/370 architecture comes in many forms  */
-
-static const bfd_arch_info_type *i370_compatible
-  PARAMS ((const bfd_arch_info_type *, const bfd_arch_info_type *));
-
-static const bfd_arch_info_type *
-i370_compatible (a, b)
-     const bfd_arch_info_type *a;
-     const bfd_arch_info_type *b;
-{
-  BFD_ASSERT (a->arch == bfd_arch_i370);
-  switch (b->arch)
-    {
-    default:
-      return NULL;
-    case bfd_arch_i370:
-      return bfd_default_compatible (a, b);
-    }
-  /*NOTREACHED*/
-}
-
 static const bfd_arch_info_type arch_info_struct[] =
 {
   /* hack alert: old old machines are really 16 and 24 bit arch ...  */
@@ -58,7 +37,7 @@ static const bfd_arch_info_type arch_inf
     "i370:360",
     3,
     false, /* not the default */
-    i370_compatible,
+    bfd_default_compatible,
     bfd_default_scan,
     &arch_info_struct[1]
   },
@@ -72,7 +51,7 @@ static const bfd_arch_info_type arch_inf
     "i370:370",
     3,
     false, /* not the default */
-    i370_compatible,
+    bfd_default_compatible,
     bfd_default_scan,
     0
   },
@@ -89,7 +68,7 @@ const bfd_arch_info_type bfd_i370_arch =
     "i370:common",
     3,
     true, /* the default */
-    i370_compatible,
+    bfd_default_compatible,
     bfd_default_scan,
     &arch_info_struct[0]
   };
Index: bfd/cpu-i386.c
===================================================================
RCS file: /cvs/src/src/bfd/cpu-i386.c,v
retrieving revision 1.7
diff -u -p -r1.7 cpu-i386.c
--- cpu-i386.c	2002/03/12 13:16:05	1.7
+++ cpu-i386.c	2002/03/13 06:45:55
@@ -22,22 +22,6 @@ Foundation, Inc., 59 Temple Place - Suit
 #include "sysdep.h"
 #include "libbfd.h"
 
-/* Don't mix 32 bit and 64 bit files.  */
-
-static const bfd_arch_info_type *i386_compatible
-  PARAMS ((const bfd_arch_info_type *, const bfd_arch_info_type *));
-
-static const bfd_arch_info_type *
-i386_compatible (a, b)
-     const bfd_arch_info_type *a;
-     const bfd_arch_info_type *b;
-{
-  if (a->bits_per_word != b->bits_per_word)
-    return NULL;
-
-  return bfd_default_compatible (a, b);
-}
-  
 const bfd_arch_info_type bfd_i386_arch_intel_syntax =
 {
   32,	/* 32 bits in a word */
@@ -49,7 +33,7 @@ const bfd_arch_info_type bfd_i386_arch_i
   "i386:intel",
   3,
   true,
-  i386_compatible,
+  bfd_default_compatible,
   bfd_default_scan ,
   0,
 };
@@ -64,7 +48,7 @@ const bfd_arch_info_type bfd_x86_64_arch
   "x86-64:intel",
   3,
   true,
-  i386_compatible,
+  bfd_default_compatible,
   bfd_default_scan ,
   &bfd_i386_arch_intel_syntax,
 };
@@ -79,7 +63,7 @@ static const bfd_arch_info_type i8086_ar
   "i8086",
   3,
   false,
-  i386_compatible,
+  bfd_default_compatible,
   bfd_default_scan ,
   &bfd_x86_64_arch_intel_syntax,
 };
@@ -95,7 +79,7 @@ const bfd_arch_info_type bfd_x86_64_arch
   "x86-64",
   3,
   true,
-  i386_compatible,
+  bfd_default_compatible,
   bfd_default_scan ,
   &i8086_arch,
 };
@@ -111,7 +95,7 @@ const bfd_arch_info_type bfd_i386_arch =
   "i386",
   3,
   true,
-  i386_compatible,
+  bfd_default_compatible,
   bfd_default_scan ,
   &bfd_x86_64_arch
 };
Index: bfd/cpu-sparc.c
===================================================================
RCS file: /cvs/src/src/bfd/cpu-sparc.c,v
retrieving revision 1.4
diff -u -p -r1.4 cpu-sparc.c
--- cpu-sparc.c	2001/03/08 21:03:58	1.4
+++ cpu-sparc.c	2002/03/13 06:45:55
@@ -1,5 +1,6 @@
 /* BFD support for the SPARC architecture.
-   Copyright 1992, 1995, 1996, 1998, 2000 Free Software Foundation, Inc.
+   Copyright 1992, 1995, 1996, 1998, 2000, 2002
+   Free Software Foundation, Inc.
 
 This file is part of BFD, the Binary File Descriptor library.
 
@@ -21,22 +22,6 @@ Foundation, Inc., 59 Temple Place - Suit
 #include "sysdep.h"
 #include "libbfd.h"
 
-/* Don't mix 32 bit and 64 bit files.  */
-
-static const bfd_arch_info_type *sparc_compatible
-  PARAMS ((const bfd_arch_info_type *, const bfd_arch_info_type *));
-
-static const bfd_arch_info_type *
-sparc_compatible (a, b)
-     const bfd_arch_info_type *a;
-     const bfd_arch_info_type *b;
-{
-  if (a->bits_per_word != b->bits_per_word)
-    return NULL;
-
-  return bfd_default_compatible (a, b);
-}
-
 static const bfd_arch_info_type arch_info_struct[] =
 {
   {
@@ -49,7 +34,7 @@ static const bfd_arch_info_type arch_inf
     "sparc:sparclet",
     3,
     false,
-    sparc_compatible,
+    bfd_default_compatible,
     bfd_default_scan,
     &arch_info_struct[1],
   },
@@ -63,7 +48,7 @@ static const bfd_arch_info_type arch_inf
     "sparc:sparclite",
     3,
     false,
-    sparc_compatible,
+    bfd_default_compatible,
     bfd_default_scan,
     &arch_info_struct[2],
   },
@@ -77,7 +62,7 @@ static const bfd_arch_info_type arch_inf
     "sparc:v8plus",
     3,
     false,
-    sparc_compatible,
+    bfd_default_compatible,
     bfd_default_scan,
     &arch_info_struct[3],
   },
@@ -91,7 +76,7 @@ static const bfd_arch_info_type arch_inf
     "sparc:v8plusa",
     3,
     false,
-    sparc_compatible,
+    bfd_default_compatible,
     bfd_default_scan,
     &arch_info_struct[4],
   },
@@ -105,7 +90,7 @@ static const bfd_arch_info_type arch_inf
     "sparc:sparclite_le",
     3,
     false,
-    sparc_compatible,
+    bfd_default_compatible,
     bfd_default_scan,
     &arch_info_struct[5],
   },
@@ -119,7 +104,7 @@ static const bfd_arch_info_type arch_inf
     "sparc:v9",
     3,
     false,
-    sparc_compatible,
+    bfd_default_compatible,
     bfd_default_scan,
     &arch_info_struct[6],
   },
@@ -133,7 +118,7 @@ static const bfd_arch_info_type arch_inf
     "sparc:v9a",
     3,
     false,
-    sparc_compatible,
+    bfd_default_compatible,
     bfd_default_scan,
     &arch_info_struct[7],
   },
@@ -147,7 +132,7 @@ static const bfd_arch_info_type arch_inf
     "sparc:v8plusb",
     3,
     false,
-    sparc_compatible,
+    bfd_default_compatible,
     bfd_default_scan,
     &arch_info_struct[8],
   },
@@ -161,7 +146,7 @@ static const bfd_arch_info_type arch_inf
     "sparc:v9b",
     3,
     false,
-    sparc_compatible,
+    bfd_default_compatible,
     bfd_default_scan,
     0,
   }
@@ -178,7 +163,7 @@ const bfd_arch_info_type bfd_sparc_arch 
     "sparc",
     3,
     true, /* the default */
-    sparc_compatible,
+    bfd_default_compatible,
     bfd_default_scan,
     &arch_info_struct[0],
   };
-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Not linking 32-bit and 64-bit objects

[David O'Brien]

On Wed, Mar 13, 2002 at 01:25:19PM +1030, Alan Modra wrote:
> This should stop the linker trying to do silly things with incompatible
> relocs.
>
> 
> bfd/ChangeLog
> 	* elflink.h (elf_bfd_final_link): Only call elf_link_input_bfd
> 	when word size of input matches output word size.
> 
> ld/ChangeLog
> 	* ldlang.c (lang_check): Do relocatable link checks first, so that
> 	warn_mismatch can't override.  Check compatible and word size too.
 
I would love to see this committed to the 2.12 branch.  The lack of of a
good error message delayed getting BU 2.12 working on FreeBSD/sparc64 by
2 weeks due to a trivial human error.

Re: Not linking 32-bit and 64-bit objects

[cgd]

At Sat, 16 Mar 2002 18:26:19 +0000 (UTC), "David O'Brien" wrote:
> I would love to see this committed to the 2.12 branch.  The lack of of a
> good error message delayed getting BU 2.12 working on FreeBSD/sparc64 by
> 2 weeks due to a trivial human error.

If this is the patch I think it is, I believe those of us over in
MIPS-land believe it (and the subsequent adjustments) is incorrect for
MIPS...


chris

Re: Not linking 32-bit and 64-bit objects

[David O'Brien]

On Sat, Mar 16, 2002 at 12:10:49PM -0800, cgd@broadcom.com wrote:
> At Sat, 16 Mar 2002 18:26:19 +0000 (UTC), "David O'Brien" wrote:
> > I would love to see this committed to the 2.12 branch.  The lack of of a
> > good error message delayed getting BU 2.12 working on FreeBSD/sparc64 by
> > 2 weeks due to a trivial human error.
> 
> If this is the patch I think it is, I believe those of us over in
> MIPS-land believe it (and the subsequent adjustments) is incorrect for
> MIPS...

Then it presumable cannot be committed to mainline yet -- which must
happen before it could be merged back to the 2.12 branch. :-)

Re: Not linking 32-bit and 64-bit objects

[Daniel Jacobowitz]

On Sat, Mar 16, 2002 at 12:21:20PM -0800, David O'Brien wrote:
> On Sat, Mar 16, 2002 at 12:10:49PM -0800, cgd@broadcom.com wrote:
> > At Sat, 16 Mar 2002 18:26:19 +0000 (UTC), "David O'Brien" wrote:
> > > I would love to see this committed to the 2.12 branch.  The lack of of a
> > > good error message delayed getting BU 2.12 working on FreeBSD/sparc64 by
> > > 2 weeks due to a trivial human error.
> > 
> > If this is the patch I think it is, I believe those of us over in
> > MIPS-land believe it (and the subsequent adjustments) is incorrect for
> > MIPS...
> 
> Then it presumable cannot be committed to mainline yet -- which must
> happen before it could be merged back to the 2.12 branch. :-)

No, it's already on the mainline.  That's the point of having a
mainline, and of not committing things to the branch immediately :)
When the branch reopens, which will probably be tonight if I have time
to organize myself, then these patches can move there - but not until
MIPS is fixed on the mainline, so that they can all go over together.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer