[parisc-linux] new binutils/gcc

[parisc-linux] new binutils/gcc

[willy]

As some of you may have noticed, we now have new binutils and gcc in CVS.
If you previously checked out binutils and/or egcs, you should probably
delete them and get a fresh checkout.  Thanks to Cygnus, this is the
ELF-supporting toolchain.  Thanks to Sammy, this includes sufficient
support for 32-bit ELF to link a kernel.  I've asked him to hold off for
a few days on checking in the kernel changes until everyone has the new
toolchain installed and we have depots/rpms/debs/whatever available.

If you're too impatient or want to hack the toolchain, here's my experience
with it so far on HPUX 11:

install GNU flex.  ld won't build with hpux lex, alas.
install GNU bison.  gcc doesn't even attempt to use yacc.

cvs co binutils
mkdir binutils-build
cd binutils-build
./binutils/configure --target=hppa1.1-linux --prefix=/home/willy/gcc \
	--host=hppa-hpux --disable-nls
make
make install

PATH=/home/willy/gcc/bin:$PATH

cvs co gcc
mkdir gcc-build
cd gcc-build
./gcc/configure --target=hppa1.1-linux --prefix=/home/willy/gcc \
	--host=hppa1.1-hpux --disable-nls
make

and then it dies while making libgcc2.a.  I'll look at it more tomorrow,
but this may save some people some time.

Re: [parisc-linux] new binutils/gcc

[willy]

ok, I couldn't wait till tomorrow..

You'll need an include directory.  You can either do it the way I did
(pick them out of glibc, one at a time), or you can get a tarball of
the fruits of my labour:

ftp://puffin.external.hp.com/pub/parisc/src/include.tar.gz

Plop this into your $prefix after installing binutils.  ie this was the
contents of /home/willy/gcc/include.  Now you need to persuade gcc to look
there for it (I thought it was supposed to do that automatically, but it seems
not).  Change line 370 of gcc-build/gcc/Makefile to read:

LIBGCC2_INCLUDES = -I/home/willy/gcc/include

and then type make.  Now I get to :

Testing libgcc1.  Ignore linker warning messages.
/home/willy/cvs/gcc-build/gcc/xgcc -B/home/willy/cvs/gcc-build/gcc/ \
	-B/home/willy/gcc/hppa1.1-linux/bin/ \
	-I/home/willy/gcc/hppa1.1-linux/include -DCROSS_COMPILE -DIN_GCC \
	-DMULTIBYTE_CHARS=1   -g -O2  -I./include  libgcc1-test.o \
	-o libgcc1-test \
  -nostartfiles -nostdlib `/home/willy/cvs/gcc-build/gcc/xgcc \
	-B/home/willy/cvs/gcc-build/gcc/ -B/home/willy/gcc/hppa1.1-linux/bin/ \
	-I/home/willy/gcc/hppa1.1-linux/include --print-libgcc-file-name`
/home/willy/gcc/hppa1.1-linux/bin/ld: can not size stub section: Bad value
libgcc1-test.o: In function `main_without__main':
/home/willy/cvs/gcc-build/gcc/../../gcc/gcc/libgcc1-test.c:20: undefined reference to `$$divI'
/home/willy/cvs/gcc-build/gcc/../../gcc/gcc/libgcc1-test.c:14: undefined reference to `$global$'
death: $$divI type 1
collect2: ld returned 1 exit status
make[1]: *** [libgcc1-test] Error 1

(wrapped for better mailer handling)

And with that I really am going to bed.  g'night.

Re: [parisc-linux] new binutils/gcc

[Paul Bame]

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.

2) I'm seeing death in an infinite loop in flush_instruction_tlb and
it looks as though it's because cache_info has not been initialized yet.

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 :-)

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

	-Paul Bame

Re: [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.

Re: [parisc-linux] new binutils/gcc

[Paul Bame]

= 
= 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())

Don't "be" branches cause a pipeline flush?  It might be faster to
do two "bl" branches instead?

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

Ok, I fixed head.S and interruption.S.  After hacking on vmlinux.lds
and a couple small other things, the elf kernel boots to the point
where I need a ramdisk or NFS root to go further, so that's my plan.
Sources are in CVS with the ELF_BRANCH tag.

Things to do:

    The init_task_union alignment is in both vmlinux.lds and
    is known by setup.c and #defined yet another place.  This ought
    to be cleaned up if possible.

    The init_task_union printf in setup.c should be fixed.

    It's probably time to start using the __setup stuff we hacked
    around for SOM.

    Fix 'make Image' or nuke it.  'make palo' works (for me anyway)

    Sammy said, and I didn't touch these (though others have in the
    main line):

	I guarantee that launching som/elf binaries won't work.  page faulting
	looks messed up somewhere.

	execve() might not work in this one..   I played with the assembler for
	it, but good things never happened, so no changes included.


			-Paul Bame