ld bug?

ld bug?

[Takashi Oe]

Hi,

Well, I've just had a kernel hang at "Freeing unused kernel memory:..."
with linux-2.4.0-test8 + numerous patches, and I've traced the hang to
what apears (to me) to be a ld bug.

The kernel hangs at the call to spin_unlock_irq() in schedule() of
kernel/sched.c.  For me (UP kernel), spin_unlock_irq() is defined to be

struct int_control_struct
{
	void (*int_cli)(void);
	void (*int_sti)(void);
	void (*int_restore_flags)(unsigned long);
	void (*int_save_flags)(unsigned long *);
	void (*int_set_lost)(unsigned long);
};
extern struct int_control_struct int_control;

extern void __no_use_sti(void);

#define __sti()			int_control.int_sti()
#define local_irq_enable()	__sti()
#define spin_unlock(lock)	do { } while (0)
#define spin_unlock_irq(lock)	\
	do { spin_unlock(lock);  local_irq_enable();       } while (0)


>From objdump output of kernel/sched.o:

     458:       3d 20 00 00     lis     r9,0
                        45a: R_PPC_ADDR16_HA    int_control+0x4
     45c:       80 09 00 04     lwz     r0,4(r9)
                        45e: R_PPC_ADDR16_LO    int_control+0x4
     460:       7c 08 03 a6     mtlr    r0
     464:       4e 80 00 21     blrl

So, if I'm reading this correctly, the compiler is generating correct
assembly.  Now, objdump output of vmlinux (kernel) for the same segment
says:

c02164c4:       3d 20 c0 3a     lis     r9,-16326
c02164c8:       80 09 c3 e4     lwz     r0,-15388(r9)
c02164cc:       7c 08 03 a6     mtlr    r0
c02164d0:       4e 80 00 21     blrl

However, from "nm vmlinux | grep int_control", "int_control" is at

c039c3e0 D int_control

as opposed to c03ac3e0 used in vmlinux.  So, it appears that ld or
something is acting up.  I've tried various version of binutils from
2.9.1.0.990418 to 2.10.0.18, but all have produced the same output.
Except for 2.9.1.0.990414, all 2.10.x versions that I tried are from
ftp://devel.linuxppc.org/users/fsirl/R5/RPMS/.

gcc is 2.95.3-2c (also from fsirl directory).

If I change some totally (and seemingly) unrelated files a bit, vmlinux
produced may be correct.  I tried to look at if any section's size
matters, but I don't see any pattern unfortunately.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ld bug?

[Iain Sandoe]

> c039c3e0 D int_control
>
> as opposed to c03ac3e0 used in vmlinux.  So, it appears that ld or

This looks about the same as the difference reported by ksymoops (when it
refuses to work - reporting a mismatch between System.map and /proc/ksyms).

but I was seeing that on 2.2.17 (however, using the toolchain upgrades
recommended for 2.4.0).

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ld bug?

[Kaoru Fukui]

From: Takashi Oe <toe@unlserve.unl.edu>
To: linuxppc-dev@lists.linuxppc.org
Subject: ld bug?
Date: Thu, 14 Sep 2000 21:28:46 -0500 (CDT)

>
> Hi,

> as opposed to c03ac3e0 used in vmlinux.  So, it appears that ld or
> something is acting up.  I've tried various version of binutils from
> 2.9.1.0.990418 to 2.10.0.18, but all have produced the same output.
> Except for 2.9.1.0.990414, all 2.10.x versions that I tried are from
> ftp://devel.linuxppc.org/users/fsirl/R5/RPMS/.
>
> gcc is 2.95.3-2c (also from fsirl directory).
>
> If I change some totally (and seemingly) unrelated files a bit, vmlinux
> produced may be correct.  I tried to look at if any section's size
> matters, but I don't see any pattern unfortunately.
>

Lastest binutls is  2.10.0.24.

It's there.

ftp://ftp.valinux.com/pub/support/hjl/binutils/

Kaoru

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ld bug?

[Paul Mackerras]

Takashi Oe writes:

> Well, I've just had a kernel hang at "Freeing unused kernel memory:..."
> with linux-2.4.0-test8 + numerous patches, and I've traced the hang to
> what apears (to me) to be a ld bug.

Don't think so, see below...

> The kernel hangs at the call to spin_unlock_irq() in schedule() of
> kernel/sched.c.  For me (UP kernel), spin_unlock_irq() is defined to be

That sounds to me like an unhandled interrupt, endlessly repeated.

> So, if I'm reading this correctly, the compiler is generating correct
> assembly.  Now, objdump output of vmlinux (kernel) for the same segment
> says:
>
> c02164c4:       3d 20 c0 3a     lis     r9,-16326
> c02164c8:       80 09 c3 e4     lwz     r0,-15388(r9)
> c02164cc:       7c 08 03 a6     mtlr    r0
> c02164d0:       4e 80 00 21     blrl
>
> However, from "nm vmlinux | grep int_control", "int_control" is at
>
> c039c3e0 D int_control

No, it's right, the thing is that the -15388 in the lwz instruction is
sign-extended.  So the address it uses is 0xc03a0000 - 15388 (or put
another way, 0xc03a0000 + 0xffffc3e4) which is in 0xc039c3e0.

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ld bug?

[Takashi Oe]

Hi,

On Fri, 15 Sep 2000, Paul Mackerras wrote:

> Takashi Oe writes:
>
> > Well, I've just had a kernel hang at "Freeing unused kernel memory:..."
> > with linux-2.4.0-test8 + numerous patches, and I've traced the hang to
> > what apears (to me) to be a ld bug.
>
> Don't think so, see below...
>
> > The kernel hangs at the call to spin_unlock_irq() in schedule() of
> > kernel/sched.c.  For me (UP kernel), spin_unlock_irq() is defined to be
>
> That sounds to me like an unhandled interrupt, endlessly repeated.

To be more precise on the "hang", the cursor is blinking normally as if
something will happen shortly (but won't), and I can invoke xmon via NMI
just fine.  When I invoked xmon, LR is at right after spin_unlock_irq()
and PC is at "blr" of __no_use_sti(), so obviously my previous
interpretation was way wrong.  Sorry.

[...]
> > However, from "nm vmlinux | grep int_control", "int_control" is at
> >
> > c039c3e0 D int_control
>
> No, it's right, the thing is that the -15388 in the lwz instruction is
> sign-extended.  So the address it uses is 0xc03a0000 - 15388 (or put
> another way, 0xc03a0000 + 0xffffc3e4) which is in 0xc039c3e0.

Thanks!  That makes a lot of sense.  I'm really glad I don't have to
compile binutils myself.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ld bug?

[mikejc]

I believe that ld has done the right thing here.

The lwz instruction sign extends the displacement when calculating r9 +
0xc3e4.

at the lwz instruction:

lis r9,-16326        r9 = 0xc03a0000

lwz r0,-15388(r9)         0xc03a0000   (r9)
                        + 0xffffc3e4   (displacement)
                          ----------
                     ea = 0xc039c3e4


Mike Corrigan



Hi,

Well, I've just had a kernel hang at "Freeing unused kernel memory:..."
with linux-2.4.0-test8 + numerous patches, and I've traced the hang to
what apears (to me) to be a ld bug.

The kernel hangs at the call to spin_unlock_irq() in schedule() of
kernel/sched.c.  For me (UP kernel), spin_unlock_irq() is defined to be

struct int_control_struct
{
     void (*int_cli)(void);
     void (*int_sti)(void);
     void (*int_restore_flags)(unsigned long);
     void (*int_save_flags)(unsigned long *);
     void (*int_set_lost)(unsigned long);
};
extern struct int_control_struct int_control;

extern void __no_use_sti(void);

#define __sti()               int_control.int_sti()
#define local_irq_enable()    __sti()
#define spin_unlock(lock)     do { } while (0)
#define spin_unlock_irq(lock) \
     do { spin_unlock(lock);  local_irq_enable();       } while (0)


>From objdump output of kernel/sched.o:

     458:       3d 20 00 00     lis     r9,0
                        45a: R_PPC_ADDR16_HA    int_control+0x4
     45c:       80 09 00 04     lwz     r0,4(r9)
                        45e: R_PPC_ADDR16_LO    int_control+0x4
     460:       7c 08 03 a6     mtlr    r0
     464:       4e 80 00 21     blrl

So, if I'm reading this correctly, the compiler is generating correct
assembly.  Now, objdump output of vmlinux (kernel) for the same segment
says:

c02164c4:       3d 20 c0 3a     lis     r9,-16326
c02164c8:       80 09 c3 e4     lwz     r0,-15388(r9)
c02164cc:       7c 08 03 a6     mtlr    r0
c02164d0:       4e 80 00 21     blrl

However, from "nm vmlinux | grep int_control", "int_control" is at

c039c3e0 D int_control

as opposed to c03ac3e0 used in vmlinux.  So, it appears that ld or
something is acting up.  I've tried various version of binutils from
2.9.1.0.990418 to 2.10.0.18, but all have produced the same output.
Except for 2.9.1.0.990414, all 2.10.x versions that I tried are from
ftp://devel.linuxppc.org/users/fsirl/R5/RPMS/.

gcc is 2.95.3-2c (also from fsirl directory).

If I change some totally (and seemingly) unrelated files a bit, vmlinux
produced may be correct.  I tried to look at if any section's size
matters, but I don't see any pattern unfortunately.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ld bug?

[Takashi Oe]

On Fri, 15 Sep 2000 mikejc@us.ibm.com wrote:

> I believe that ld has done the right thing here.

Yes, right!  It's my thinko.  Paul had explained to me in details
yesterday.

I still don't understand why (seemingly) completely unrelated change
results in a bad kernel (just idling doing nothing), however  :(


Thanks!

Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/