[parisc-linux] Linker problems

[parisc-linux] Linker problems

[Alex deVries]

When I build the current kernel in CVS, it gets remarkably far, then dies
on:

parisc-linux-ld -m hppaelf -e stext arch/parisc/kernel/head.o
arch/parisc/kernel/init_task.o init/main.o init/version.o \
        --start-group \
        arch/parisc/kernel/kernel.o arch/parisc/mm/mm.o kernel/kernel.o
mm/mm.o fs/fs.o ipc/ipc.o \
        fs/filesystems.a \
        net/network.a \
        drivers/block/block.a drivers/char/char.a drivers/misc/misc.a
drivers/net/net.a drivers/video/video.a \
        /usr/src/parisc/work/linux/arch/parisc/lib/lib.a
/usr/src/parisc/work/linux/lib/lib.a
/usr/src/parisc/work/linux/arch/parisc/lib/lib.a \
        --end-group \
        -o vmlinux
make: *** [vmlinux] Aborted (core dumped)
make: *** Deleting file `vmlinux'

That's remarkably gross, since it indicates that there's a problem with
the linker.  I'm not quite sure what it is, but the problem seems to come
up when it's processing lib/libc.a.

I think that's a good thing for someone to look into.

- Alex

-- 
Alex deVries <puffin@redhat.com>     
Red Hat Contrib Net maintainer          
Ottawa, Canada  
PA RISC Linux Porting Team

Re: [parisc-linux] Linker problems

[Mike Shaver]

Alex deVries wrote:
> make: *** [vmlinux] Aborted (core dumped)
> make: *** Deleting file `vmlinux'
> 
> That's remarkably gross, since it indicates that there's a problem with
> the linker.  I'm not quite sure what it is, but the problem seems to come
> up when it's processing lib/libc.a.
> 
> I think that's a good thing for someone to look into.

IIRC, Nat says it's a matter of popping into gdb, spotting the crash
location, fixing the obvious double-free and recompiling.

Mike

-- 
372738.81 362322.32

Re: [parisc-linux] Linker problems

[Philipp Rumpf]

> That's remarkably gross, since it indicates that there's a problem with
> the linker.  I'm not quite sure what it is, but the problem seems to come

I think I have fixed it in CVS. Please all retry 8)

> I think that's a good thing for someone to look into.

Still, someone could look into whether what I have done was right, so the
comments in the code seem to imply very strongly to me it is.

binutils/ld/emultempl/hppaelf.em is now version 1.2, was version 1.1.

	Philipp

Re: [parisc-linux] Linker problems

[Philipp Rumpf]

> binutils/ld/emultempl/hppaelf.em is now version 1.2, was version 1.1.

I typoed there, use 1.4. We now die with an undefined reference to $global$.
should not be exactly hard to fix I guess but it is 5am here :)

Re: [parisc-linux] Linker problems

[Philipp Rumpf]

> I typoed there, use 1.4. We now die with an undefined reference to $global$.
> should not be exactly hard to fix I guess but it is 5am here :)

not hard at all. here we are:

prumpf@insula:~/cvs-s/parisc/linux > ls -l vmlinux 
-rwxr-xr-x   1 prumpf   users      353695 May  1 03:01 vmlinux

I'll commit the $global$ change now. someone tell me how far the boot gets,
ok ? (not that I expect much).

[parisc-linux] The kernel builds!!!

[Alex deVries]

On Sat, 1 May 1999, Philipp Rumpf wrote:
> prumpf@insula:~/cvs-s/parisc/linux > ls -l vmlinux 
> -rwxr-xr-x   1 prumpf   users      353695 May  1 03:01 vmlinux
> 

I'm pretty sure that this is the first every monolithic kernel to be build
for PA RISC.

This is a pretty significant feat, and I'd encourage you wherever you are
to stand up and clap your hands/wings to Philipp and everyone else who's
helped out. 

This is going very very well... I hope people can appreciate the
significance of this step.

- Alex

-- 
Alex deVries <puffin@redhat.com>     
Red Hat Contrib Net maintainer          
Ottawa, Canada  
PA RISC Linux Porting Team

Re: [parisc-linux] The kernel builds!!!

[Hugo van der Kooij]

On Sat, 1 May 1999, Alex deVries wrote:

> 
> On Sat, 1 May 1999, Philipp Rumpf wrote:
> > prumpf@insula:~/cvs-s/parisc/linux > ls -l vmlinux 
> > -rwxr-xr-x   1 prumpf   users      353695 May  1 03:01 vmlinux
> > 
> 
> I'm pretty sure that this is the first every monolithic kernel to be build
> for PA RISC.
> 
> This is a pretty significant feat, and I'd encourage you wherever you are
> to stand up and clap your hands/wings to Philipp and everyone else who's
> helped out. 

The mere fact is more then a leap for mankind.

GREAT JOB!

Hugo.

        +------------------------+------------------------------+
        | Hugo van der Kooij     | Hugo.van.der.Kooij@caiw.nl   |
        | Oranje Nassaustraat 16 | http://www.caiw.nl/~hvdkooij |
        | 3155 VJ  Maasland      | (De man met de rode hoed)    |
        +------------------------+------------------------------+
    "Computers let you make more mistakes faster than any other invention in
      human history, with the possible exception of handguns and tequila."
                (Mitch Radcliffe)

[parisc-linux] Linker problems

[Philipp Rumpf]

Okay, it looks like HP/UX ld is behaving funny for some things in the 2.3
kernel.  Most notable fs/buffer.c, buffer_init:

Assembly source piped to gas:
	addil LR'hash_table-$global$,%r27
	copy %r1,%r12
	addil LR'bh_hash_shift-$global$,%r27
	copy %r1,%r10
	addil LR'zonelists-$global$,%r27
	comib,>>= 1,%r3,L$4451

Generated object file (objdump -d --reloc fs/buffer.o):
      84:   2b 60 00 00     addil 0,dp,%r1
                        84: R_DP_RELATIVE       hash_table
      88:   08 01 02 4c     copy r1,r12
      8c:   2b 60 00 00     addil 0,dp,%r1
                        8c: R_DP_RELATIVE       bh_hash_shift
      90:   08 01 02 4a     copy r1,r10
      94:   2b 60 00 00     addil 0,dp,%r1
                        94: R_DP_RELATIVE       zonelists
      98:   8c 62 80 30     cmpib,>>= 1,r3,b8 <buffer_init+0xb8>

vmlinux (objdump -d --reloc vmlinux):
c0063884:       2b 70 30 00     addil 21800,dp,%r1
c0063888:       08 01 02 4c     copy r1,r12
c006388c:       28 0f 70 00     addil 5f800,r0,%r1
c0063890:       08 01 02 4a     copy r1,r10
c0063894:       2b 77 50 00     addil 6e800,dp,%r1
c0063898:       8c 62 80 30     cmpib,>>= 1,r3,c00638b8 <buffer_init+0xb8>


Note that 
	addil LR'bh_hash_shift-$global$,%r27
	copy %r1,%r10

ultimately becomes addil 0x5f800, _r0_, %r1, which doesn't make sense (and
causes a DPF lateron).

I haven't found anything obvious that could explain it in the linker source,
but I haven't looked too closely at it.

Sorting this out is pretty much required to get 2.3 up (otoh, we're getting to
buffer_init which is relatively far (into the parts that have changed heavily)).

Any ideas ?


	Philipp Rumpf

Re: [parisc-linux] Linker problems

[Philipp Rumpf]

> I just verified that the problem exists with the linker as compiled from the
> GPL'd source (which required some minor modifications to the CVS ld).

Here's the diff against fixups.c (including stuff I added to ignore
R_SHORT_PCREL_MODE which we get for some reason (that might be a gas
funny)).

diff -ur linker-cvs/fixups.c linker/fixups.c
--- linker-cvs/fixups.c	Mon Dec  6 20:21:23 1999
+++ linker/fixups.c	Mon Dec  6 20:27:03 1999
@@ -360,6 +360,10 @@
     /*  PA2.0 instructions */
     {   R_SHORT_PCREL_MODE,  1,   1,      NONE,   NONE,  NONE   },
     {   R_LONG_PCREL_MODE,   1,   1,      NONE,   NONE,  NONE   },
+#else
+	/* we seem to get R_SHORT_PCREL_MODE -- which I guess is the "do the
+	 * PA1.1 thing" one which would mean we can just ignore it.  prumpf */
+    {   R_SHORT_PCREL_MODE,  1,   1,      NONE,   NONE,  NONE   },
 #endif /* ifdef PA_2_0 */
     {   R_ABS_CALL        , 10,   2,      AR_D,   U_8,   NONE   },
     {   0                 ,  2,   3,      AR_9,   U_8,   NONE   },
@@ -1339,6 +1343,11 @@
 		GET_NO_ARGS;
 		is_pcrel_short = FALSE;
 		break;
+#else
+	    case R_SHORT_PCREL_MODE:
+		GET_NO_ARGS;
+		/* we just ignore R_SHORT_PCREL_MODE on PA1.1.  prumpf */
+		break;
 #endif /* ifdef PA_2_0 */
 
             /* zero length, clear overrides */
@@ -4342,9 +4351,9 @@
 
     switch (fix_info->type) {
 #ifdef PA_2_0
-	case R_SHORT_PCREL_MODE:
 	case  R_LONG_PCREL_MODE:
 #endif /* ifdef PA_2_0 */
+	case R_SHORT_PCREL_MODE:
         case R_BEGIN_BRTAB:
         case R_END_BRTAB:
         case R_FSEL:
@@ -5388,7 +5397,7 @@
 	        value = symbol_value(arg0);
 		if (GET_OP(instruction) == 0x0a) {          /* if an ADDIL */
 		    /* set to addil L'sym, r0 */
-		    instruction = (instruction & REG_MASK);
+		    instruction = (instruction & REG_MASK) | R27_MASK;
 		}
 		/* else ldw/stw is set to use r1 already */
 #ifdef TSD /* TSD */


The important part is

-		    instruction = (instruction & REG_MASK);
+		    instruction = (instruction & REG_MASK) | R27_MASK;

.  I don't really know what my changes do, just the kernel links correctly
with them and doesn't without.

Anyway, kudos to the folks who convinced HP to GPL the linker in the first
place.  Otherwise, we'd be pretty stuck by now.

	Philipp Rumpf

Re: [parisc-linux] Linker problems

[Philipp Rumpf]

I just verified that the problem exists with the linker as compiled from the
GPL'd source (which required some minor modifications to the CVS ld).

	Philipp Rumpf