From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by oss.sgi.com id ; Wed, 3 Jan 2001 17:39:12 -0800 Received: from mail.cosinecom.com ([63.88.104.16]:37895 "EHLO exchsrv1.cosinecom.com") by oss.sgi.com with ESMTP id ; Wed, 3 Jan 2001 17:38:55 -0800 Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 17:36:46 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A29113D7353@exchsrv1.cosinecom.com> From: John Van Horne To: "'linux-mips@oss.sgi.com'" Cc: "'wesolows@foobazco.org'" Subject: Date: Wed, 3 Jan 2001 17:36:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C075EE.CBD95CA0" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C075EE.CBD95CA0 Content-Type: text/plain; charset="iso-8859-1" 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 ------_=_NextPart_001_01C075EE.CBD95CA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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-mip= s.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


------_=_NextPart_001_01C075EE.CBD95CA0-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 07:46:13 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:53497 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 07:45:56 -0800 Received: (ralf@lappi) by bacchus.dhis.org id ; Thu, 4 Jan 2001 13:36:29 -0200 Date: Thu, 4 Jan 2001 13:36:29 -0200 From: Ralf Baechle To: John Van Horne Cc: "'linux-mips@oss.sgi.com'" , "'wesolows@foobazco.org'" Subject: Re: your mail Message-ID: <20010104133629.C936@bacchus.dhis.org> References: <7EB7C6B62C4FD41196A80090279A29113D7353@exchsrv1.cosinecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <7EB7C6B62C4FD41196A80090279A29113D7353@exchsrv1.cosinecom.com>; from JohnVan.Horne@cosinecom.com on Wed, Jan 03, 2001 at 05:36:44PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 08:26:43 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:52141 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 08:26:20 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA11844; Thu, 4 Jan 2001 17:22:52 +0100 (MET) Date: Thu, 4 Jan 2001 17:22:51 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: John Van Horne , "'linux-mips@oss.sgi.com'" , "'wesolows@foobazco.org'" Subject: Re: your mail In-Reply-To: <20010104133629.C936@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing 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 + From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 08:49:43 -0800 Received: from blackdog.wirespeed.com ([208.170.106.25]:1546 "EHLO blackdog.wirespeed.com") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 08:49:21 -0800 Received: from redhat.com (IDENT:joe@dhcp-4.wirespeed.com [172.16.17.4]) by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id KAA09708; Thu, 4 Jan 2001 10:35:04 -0600 Message-ID: <3A54A789.1070608@redhat.com> Date: Thu, 04 Jan 2001 10:40:41 -0600 From: Joe deBlaquiere Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , John Van Horne , "'linux-mips@oss.sgi.com'" , "'wesolows@foobazco.org'" Subject: Re: your mail References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing 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). From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 09:22:53 -0800 Received: from brutus.conectiva.com.br ([200.250.58.146]:2043 "EHLO dhcp046.distro.conectiva") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 09:22:42 -0800 Received: (ralf@lappi) by bacchus.dhis.org id ; Thu, 4 Jan 2001 15:13:42 -0200 Date: Thu, 4 Jan 2001 15:13:34 -0200 From: Ralf Baechle To: Joe deBlaquiere Cc: "Maciej W. Rozycki" , John Van Horne , "'linux-mips@oss.sgi.com'" , "'wesolows@foobazco.org'" Subject: Re: your mail Message-ID: <20010104151334.C2525@bacchus.dhis.org> References: <3A54A789.1070608@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3A54A789.1070608@redhat.com>; from jadb@redhat.com on Thu, Jan 04, 2001 at 10:40:41AM -0600 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 09:32:23 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:32430 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 09:32:12 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA13739; Thu, 4 Jan 2001 18:18:42 +0100 (MET) Date: Thu, 4 Jan 2001 18:18:41 +0100 (MET) From: "Maciej W. Rozycki" To: Joe deBlaquiere cc: Ralf Baechle , John Van Horne , "'linux-mips@oss.sgi.com'" , "'wesolows@foobazco.org'" Subject: Re: your mail In-Reply-To: <3A54A789.1070608@redhat.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing 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 + From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 09:45:24 -0800 Received: from blackdog.wirespeed.com ([208.170.106.25]:41738 "EHLO blackdog.wirespeed.com") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 09:45:04 -0800 Received: from redhat.com (IDENT:joe@dhcp-4.wirespeed.com [172.16.17.4]) by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id LAA11147; Thu, 4 Jan 2001 11:40:52 -0600 Message-ID: <3A54B6F4.7000909@redhat.com> Date: Thu, 04 Jan 2001 11:46:28 -0600 From: Joe deBlaquiere Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: "Maciej W. Rozycki" , John Van Horne , "'linux-mips@oss.sgi.com'" , "'wesolows@foobazco.org'" Subject: Re: your mail References: <3A54A789.1070608@redhat.com> <20010104151334.C2525@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 10:21:25 -0800 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:25519 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 10:20:59 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA15729; Thu, 4 Jan 2001 19:12:21 +0100 (MET) Date: Thu, 4 Jan 2001 19:12:20 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Joe deBlaquiere cc: Ralf Baechle , John Van Horne , "'linux-mips@oss.sgi.com'" , "'wesolows@foobazco.org'" Subject: Re: your mail In-Reply-To: <3A54B6F4.7000909@redhat.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing 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 + From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 16:44:27 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57646 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 16:44:02 -0800 Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id QAA04955; Thu, 4 Jan 2001 16:52:40 -0800 (PST) mail_from (kaos@ocs.com.au) Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) id LAA12000; Fri, 5 Jan 2001 11:42:42 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Ralf Baechle cc: "'linux-mips@oss.sgi.com'" Subject: ksymoops on origin In-reply-to: Your message of "Thu, 04 Jan 2001 15:13:34 -0200." <20010104151334.C2525@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jan 2001 11:42:42 +1100 Message-ID: <1123.978655362@kao2.melbourne.sgi.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing On Thu, 4 Jan 2001 15:13:34 -0200, Ralf Baechle 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.