(no subject)

[John Van Horne]

[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]

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



[-- Attachment #2: Type: text/html, Size: 2640 bytes --]

Re: your mail

[Ralf Baechle]

On Wed, Jan 03, 2001 at 05:36:44PM -0800, John Van Horne wrote:

> 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?

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.

> 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.

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?

> 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.

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

Re: your mail

[Maciej W. Rozycki]

On Thu, 4 Jan 2001, Ralf Baechle wrote:

> > 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?
> 
> 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.

 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: macro@ds2.pg.gda.pl, PGP key available        +

Re: your mail

[Joe deBlaquiere]

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.

Maciej W. Rozycki wrote:

> On Thu, 4 Jan 2001, Ralf Baechle wrote:
> 
> 
>>> 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?
>> 
>> 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.
> 
> 
>  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). 

Re: your mail

[Ralf Baechle]

On Thu, Jan 04, 2001 at 10:40:41AM -0600, Joe deBlaquiere wrote:

> 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.

I couldn't care less ...

> 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.

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

Re: your mail

[Maciej W. Rozycki]

On Thu, 4 Jan 2001, Joe deBlaquiere wrote:

> 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.

 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? 

> 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.

 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.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: your mail

[Joe deBlaquiere]

Ralf Baechle wrote:

> On Thu, Jan 04, 2001 at 10:40:41AM -0600, Joe deBlaquiere wrote:
> 
> 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.
> 
> 
> 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


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

Re: your mail

[Maciej W. Rozycki]

On Thu, 4 Jan 2001, Joe deBlaquiere wrote:

> 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?

 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. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

ksymoops on origin

[Keith Owens]

On Thu, 4 Jan 2001 15:13:34 -0200, 
Ralf Baechle <ralf@oss.sgi.com> wrote:
>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.

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.