[parisc-linux] new binutils/gcc

[Sam Creasey]

On Fri, 25 Feb 2000, Paul Bame wrote:

> 
> Willy, Sammy,
> 
> I've been trying the elf stuff plus Sammy's patches, updated to work
> from the current CVS bits.  Here's what I've found so far:
> 
> 1) this compiler seems to allocate the rp and ret1 registers first
> which makes debugging from register dumps worse -- no glancing at r2
> to figure out who called ya.

hmmmmmmm...  did the function prologue stuff change much from the other
parisc compiler?

> 3) We get to start_parisc() but no C procedure calls work from there --
> even a local call is failing.  The local call, to address c0114dd4,
> generates the following branch:
> 
>     c020cbcc:       e5 00 29 38     be,l 49c(sr4,r8)
> 
> r8 = 0xc0000000 and sr4 = 0 so I think this branches to a very
> bad place.  Another branch to pdc_console_init() generates
> 
>     c020cbec:       e5 00 31 30     be,l 898(sr4,r8)
> 
> pdc_console_init is at c0101b50 T pdc_console_init
> 
> Note that I CHANGED the load address of 0xc0010000 to 0xc0100000 in
> vmlinux.lds but I can't see there's a relationship so I'm stumped and
> suspect maybe a language system bug which isn't my forte.  Enjoy :-)

There is, in fact, a relationship there.  r8 isn't set properly at any
time, it's kludged.  r8 needs to be set to 
(load addr of .text) & 0xfff00000.   Basically this is used as a pointer
to the stub table for long branching.  (so, it should be a jump to
0xc010049c, which ought to be a stub for start_parisc())

Yeah, it's kinda ugly...  the linker and crt0.S both need to be
taught about this too.

> The sources I used can be generated by applying the patch
> pehc:/tmp/sammy2 to the CVS bits current as of this morning.