Subject: Re: your mail

From: John Van Horne <[email-masked]>
Date: Wed, 3 Jan 2001 17:36:44 -0800

Hello,

I downloaded cross-all-001027.tar from
oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev,
built it on my ix86 Linux box, and have tried to use it on our Linux
application and Linux kernel.
I'm getting errors which we didn't see when we were using
binutils-mips-linux-2.8.1 and
egcs-mips-linux-1.0.3a.

First, while the kernel builds just fine, when we use objcopy to convert the
elf image into a binary
image which we can download to our target, objcopy fails with warnings
saying that it is writing
sections to huge (i.e. negative) file offsets. When I use objdump to analyze
the kernel image,
I see that our start address of 0x80102584 has been turned into
0xffffffff80102584. I'm thinking that
I need to tell ld something to stop it from doing this. Any ideas?

Second, the way we build our application, we first create a partially linked
image, with the -r flag. Then 
we run ld on this (and an additional object file). When we do this with the
tools from cross-all-001027
we get the following error on the second link step:

mips-linux-ld:  BFD internal error, aborting at
/homes/local/mips-cross/crossdev-build/src/binutils-001027/bfd/elf32-mips.c
line 6942 in _bfd_mips_elf_relocate_section

mips-linux-ld: Please report this bug.

Actually, on the application we didn't get this far using
binutils-mips-linux-2.8.1 and egcs-mips-linux-1.0.3a,
so I have nothing to compare it to.  I'm not sure if this is a bug or if I
should be passing some flags to gcc or ld.

Any help you can provide would be appreciated.

Thanks,
-John

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 4 Jan 2001 13:36:29 -0200

> I need to tell ld something to stop it from doing this. Any ideas?

That's be ok.  32-bit MIPS addresses are sign-extended into 64-bit addresses.
Older binutils used to zero-extend addresses which was broken.  So what
you observe is actually the sympthom of a bug that got fixed.

> mips-linux-ld: Please report this bug.

Not good ...  Two possibilities.

 - it's fairly easy to make ld die in funny ways by feeding it with nonsense
   options, linker scripts or similar.
 - it's really a bug.

Assuming it's really a bug, can you extract a small test case that
demonstrate this bug?

> should be passing some flags to gcc or ld.

It may well be a bug; especially -r is used relativly rarely so the code
isn't getting excercised too well.  I'd like to see it get fixed in the
current linker, though.

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Thu, 4 Jan 2001 17:22:51 +0100 (MET)

> you observe is actually the sympthom of a bug that got fixed.

 I'm not sure that's the best solution, I'm afraid.  For elf32-mips
addresses should be 32-bit and not 64-bit.  It would be consistent with
other 32-bit platforms, it would make interoperability easier (ksymoops
cannot make use of System.map to grok kernel oopses which provide 32-bit
addresses) and it would make objdump outputs more readable.

 Fixing this problem with BFD is on my to do list (but has a low priority
assigned). 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Joe deBlaquiere <[email-masked]>
Date: Thu, 04 Jan 2001 10:40:41 -0600

If the BFD stuff is built with any support for 64 bit (even as an 
optional target) it will maintain all addresses as 64-bit values, even 
if the file is 32 bit.

There is a bug in that "some" newer versions of objcopy will not allow 
you to translate these sign-extended 32 bit addresses into Intel Hex 
format.

If you're really only doing 32-bit mips you might consider removing the 
64 bit targets in the config.bfd... I think that will solve the problems.

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 4 Jan 2001 15:13:34 -0200

> you to translate these sign-extended 32 bit addresses into Intel Hex 

I couldn't care less ...

> 64 bit targets in the config.bfd... I think that will solve the problems.

Doesn't really solve the problem.  For example on an Origin we have a 32-bit
userland but 64-bit kernel addresses which confuses ksymops and procps.

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Thu, 4 Jan 2001 18:18:41 +0100 (MET)

> optional target) it will maintain all addresses as 64-bit values, even 

 I do consider it fine BFD handles all addresses as 64-bit internally.  I
just think it should truncate them to 32-bits upon printing (and always
whenever appropriate) when the selected target is 32-bit.  It does so (it
has to!) for output anyway, so what's the deal? 

> 64 bit targets in the config.bfd... I think that will solve the problems.

 Nope, I insist 32-bit targets need to work correctly regardless of
whether there are any 64-bit ones supported by a particular BFD binary or
not.  Do you think elf32-i386 should switch to printing 64-bit addresses
if elf64-alpha is also supported by a given configuration of BFD?  I
don't.

---

From: Joe deBlaquiere <[email-masked]>
Date: Thu, 04 Jan 2001 11:46:28 -0600

> userland but 64-bit kernel addresses which confuses ksymops and procps.

It was meant as a workaround...

Perhaps we could have an option to objcopy that would allow you to copy 
the addresses without sign extension?

Joe

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Thu, 4 Jan 2001 19:12:20 +0100 (MET)

> the addresses without sign extension?

 Please do either implement a clean solution or wait until someone else
(possibly me) does.  We don't want any more hacks -- MIPS/Linux already
has enough of them.  This is my view of the situation at present.

---

From: Keith Owens <[email-masked]>
Date: Fri, 05 Jan 2001 11:42:42 +1100

On Thu, 4 Jan 2001 15:13:34 -0200, 
>userland but 64-bit kernel addresses which confuses ksymops and procps.

In what way does ksymoops get confused?  All its address handling
should be 64 bit.  As long as the kernel prints its addresses in full,
without removing the high order word, then the text handling should be
OK.  The only problem will be the default object format which is taken
from ksymoops itself.  Sparc also has this problem, from oops.c,
function Oops_eip.

        /* Special case for sparc64.  If the output target is defaulting to the
         * same format as ksymoops then the default is wrong, kernel is 64 bit,
         * ksymoops is 32 bit.  When we see an EIP from sparc64, set the correct
         * default.
         */
        if (!options->target && !options->architecture &&
            strcmp(bfd_get_target(ibfd), "elf32-sparc")) {
            options->target = "elf64-sparc";
            options->architecture = "sparc:v9a";
        }

I will add a special case for Origin if somebody can tell me:

  What oops string identifies a 64 bit kernel instead of 32 bit.
  What bfd_get_target() reports for a 32 bit ksymoops on Origin.
  What target and architecture to use for a 64 bit kernel.

Even without special case code for Origin, you can run ksymoops with
the -t and -a options to force the desired format, instead of
defaulting to the format of ksymoops.