Subject: Re: patches for egcs mainline

From: Philip Blundell <[email-masked]>
Date: Fri, 02 Apr 1999 11:56:21 +0100

>I'm guessing the R_ARM_PC24 reloc's are what ld.so is choking on,
>judging by ld.so's error message (actually, /lib/ld-linux.so.2).
>
>Should the compiler be generating R_ARM_PC24 reloc's at all?

Not with -fPIC, no.  Sounds like I screwed up somewhere and libgcc2.c isn't 
getting built as PIC (yet again).  I'll look into this later today.

p.

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Fri, 02 Apr 1999 12:15:39 +0100

>00022394 <Ldiv0>:
>   22394:       e52de004        str     lr, [sp, -#4]!
>   22398:       ebfffffe        bl      22398 <Ldiv0+0x4>

I think I forgot to include the patch to libgcc1-asm.S to add the (PLT) 
qualifiers.  D'oh.  Try copying that file out of egcs 1.1.x and see if the 
problem goes away.

p.

---

From: Jamie Guinan <[email-masked]>
Date: Fri, 2 Apr 1999 08:39:30 -0500 (EST)

> qualifiers.  D'oh.  Try copying that file out of egcs 1.1.x and see if the 

Looking at my copy of lib1funcs.asm, it appears Ok,

#ifdef __elf__
#define __PLT__ (PLT)
...
#else
#define __PLT__
...
Ldiv0:
	str	lr, [sp, #-4]!
	bl	SYM (__div0) __PLT__
	mov	r0, #0			@ about as wrong as it could be
	ldmia	sp!, {pc}RETCOND
...

I'll check to make sure that __elf__ is defined at compile time.

I also have an old patch that Scott B. made against gcc 2.8.1
which I might take for a spin,

for arm.h,
*** arm.h~	Mon Jul  6 10:26:09 1998
--- arm.h	Tue Aug 18 13:17:46 1998
***************
*** 2028,2033 ****
--- 2028,2034 ----
    fputs ("\tb\t", FILE);\
    assemble_name (FILE,\
                   IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (FUNCTION)));\
+   if (flag_pic) fputs ("(PLT)", FILE);\
    fputc ('\n', FILE);\
  } while (0)

But I wonder if this is "one of those" patches that didn't get
into the main egcs for some reason?

Anyway, I'll keep trying...

-Jamie

---

From: Jamie Guinan <[email-masked]>
Date: Fri, 2 Apr 1999 10:36:53 -0500 (EST)

> Looking at my copy of lib1funcs.asm, it appears Ok,
#error __elf__ is not defined  (I added this for testing)
> I'll check to make sure that __elf__ is defined at compile time.

Ok, in xgcc's first pass at libgcc1.S during "make bootstrap",
__elf__ is not defined, so __PLT__ is a no-op.

Is __elf__ supposed to be defined internally by xgcc at this point?
It doesn't appear to be,

$ (cd gcc; ./xgcc -dumpspecs)
...
*predefines:
-Dunix -Darm -Dlinux -Asystem(unix) -Asystem(posix) -Acpu(arm)
-Amachine(arm) -D__ELF__ -Darm_elf
...

I don't want to start putting hacks in when there's a proper
fix waiting to be found.

-Jamie

---

From: Philip Blundell <[email-masked]>
Date: Fri, 02 Apr 1999 16:51:29 +0100

>Is __elf__ supposed to be defined internally by xgcc at this point?

No.  The conditional should be #ifdef __ELF__.

p.

---

From: Jamie Guinan <[email-masked]>
Date: Fri, 2 Apr 1999 14:55:53 -0500 (EST)

(this was the "patches for egcs mainline" thread)

> No.  The conditional should be #ifdef __ELF__.

Thanks.  That indeed fixed the R_ARM_PC24 reloc problem in
libglib.

So next I tried building GTK (which depends on GLIB), and I got an
internal compiler error compiling gtkbutton.c,

../../egcs-19990328/gcc/function.c:3127: Internal compiler error in
function purge_addressof_1

function.c:3127
	  if (GET_MODE_SIZE (GET_MODE (x))
	      < GET_MODE_SIZE (GET_MODE (y)))
	    abort ();

If anyone's interested in trying it, pick up
 ftp://ftp.netwinder.org/users/g/guinan/gtkbutton.i.gz
and compile it with

$ gcc -g -O2 -Wall -c -fPIC -DPIC gtkbutton.i -o gtkbutton.o

This bug shows up in the 19990328 egcs with Phil's patches,
I don't know about other versions.

Should I submit this one to egcs-bugs?

-Jamie

---

From: Philip Blundell <[email-masked]>
Date: Fri, 02 Apr 1999 22:10:19 +0100

>Should I submit this one to egcs-bugs?

Yes, so long as you're reasonably confident it's not my fault.  There's no 
point bothering the egcs people with bugs that are caused by my patches.

If you can build an arm-elf (or even arm-linux) compiler from the current egcs 
sources with no patches and reproduce the problem with that then yes, by all 
means send it in.  I'm not 100% sure what the protocol is for reporting bugs 
in snapshot releases (ie whether you're supposed to send them to egcs-bugs or 
just the egcs list).  I imagine their web pages have the details.

p.

---

From: Stefan Hanske <[email-masked]>
Date: Thu, 15 Apr 1999 12:19:32 +0200 (METDST)

On Thu, 1 Apr 1999, Jamie Guinan wrote:

> /tmp/testEgcs1/lib/libglib-1.2.so.0.0.0:     file format elf32-arm
> 
> DYNAMIC RELOCATION RECORDS
> OFFSET   TYPE              VALUE 
> 00022398 R_ARM_PC24        __div0
> 0002244c R_ARM_PC24        __div0
> 00022500 R_ARM_PC24        __div0
> 0002d494 R_ARM_RELATIVE    *ABS*
> 0002d574 R_ARM_RELATIVE    *ABS*
> 0002d5a8 R_ARM_RELATIVE    *ABS*
> ...
> 
> Here are the relocation locations (objdump -d),

I've had this troubles, too. Make sure that all bits of libgcc.a (in the
egcs-source) are compiled with -fPIC (mainly libgcc1.{S,asm}). I think
that was the problem. 

----------------------------------------------------------
|mailto: Stefan Hanske ([email-masked] |
|WWW : http://www.rzuser.uni-heidelberg.de/~shanske      |
|phone: I'm not silly                                    |
|--------------------------------------------------------|
| And don't forget to remember what you remembered not   |
| to forget to remember...				 |
----------------------------------------------------------