From: Matt Taggart <taggart@carmen.fc.hp.com>
To: Alan Modra <alan@linuxcare.com.au>
Cc: Grant Grundler <grundler@cup.hp.com>, parisc-linux@thepuffingroup.com
Subject: Re: [parisc-linux] 32-bit xc-20001206.tar.gz is foobar
Date: Tue, 12 Dec 2000 01:28:35 -0700 [thread overview]
Message-ID: <20001212082835.698F337CA1@carmen.fc.hp.com> (raw)
In-Reply-To: Message from Alan Modra <alan@linuxcare.com.au> of "Mon, 11 Dec 2000 00:02:57 EST." <Pine.LNX.4.21.0012102347330.31734-100000@front.linuxcare.com.au>
Alan Modra writes...
> > hppa-linux-ld: fs/fs.o(.text.load_aout_interp+0x11c): cannot reach 00000010
> _flush_instruction_cache+0, recompile with -ffunction-sections
> > hppa-linux-ld: fs/fs.o(.text.load_aout_interp+0x11c): cannot handle R_PARIS
> C_PCREL17F for flush_instruction_cache
> > ...
>
> This isn't necessarily a problem with Matt's latest compiler binary. fs.o
> is produced with a "ld -r" link stage, and it's text size is larger than
> 256k, so there is potential for branches to not be able to reach stubs.
>
> ie. You may get these problems if
> a) You are using an older binutils (ie. not the latest pehc CVS version),
> and aren't using -ffunction-sections to compile the kernel
> b) You are using the very latest binutils, and aren't using
> -ffunction-sections, and I've goofed in my "ld -r" magic.
I just built a new cross-compiler (xc-20001211.tar.gz) and am still getting
similar errors when building the kernel. It doesn't seem to matter if I have
-ffunction-sections in the kernel Makefile or not.
> On a good fs.o, "hppa-linux-readelf -h fs.o" ought to show lots of .text.*
> sections.
$ hppa-linux-readelf -h fs.o
ELF Header:
Magic: 7f 45 4c 46 01 02 01 03 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - Linux
ABI Version: 0
Type: REL (Relocatable file)
Machine: HPPA
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 360836 (bytes into file)
Flags: 0x210, PA-RISC 1.1
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 92
Section header string table index: 89
HTH,
--
Matt Taggart
taggart@fc.hp.com
next prev parent reply other threads:[~2000-12-12 8:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-10 5:23 [parisc-linux] 32-bit xc-20001206.tar.gz is foobar Grant Grundler
2000-12-10 13:02 ` Alan Modra
2000-12-10 15:38 ` Roel Teuwen
2000-12-12 0:06 ` [parisc-linux] gcc wchar patch for hppa64 John David Anglin
2000-12-12 1:43 ` Alan Modra
2000-12-12 8:28 ` Matt Taggart [this message]
2000-12-12 8:37 ` [parisc-linux] 32-bit xc-20001206.tar.gz is foobar Alan Modra
2000-12-12 8:44 ` Matt Taggart
2000-12-12 9:01 ` Alan Modra
2000-12-12 10:53 ` Alan Modra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20001212082835.698F337CA1@carmen.fc.hp.com \
--to=taggart@carmen.fc.hp.com \
--cc=alan@linuxcare.com.au \
--cc=grundler@cup.hp.com \
--cc=parisc-linux@thepuffingroup.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox