Re: ld bug?

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?

[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/

Re: zeroing pages in the idle task?

[Geert Uytterhoeven]

On Wed, 13 Sep 2000, David A. Gatwood wrote:
> On Wed, 13 Sep 2000, Takashi Oe wrote:
> > > Since the only use of this number is for oohs and aahs, there's not a
> > > lot of motivation to try and work out if OF is wrong and work out the
> > > correct number.
> >
> > Could you possibly tell me how one might implement this?  That is: how one
> > would measure/calculate this.  On NuBus, there is no OF, so I'd like to
> > implement.
>
> Ask the guys at Newer Tech for their Clockometer sources.  I don't know if
> they'd be willing to open-source them, but it's worth a shot.  As I
> understand it, their program does just what you're looking for.

On the m68k, we have some code to guestimate the CPU clock based on the
BogoMIPS (see get_cpuinfo() in arch/m68k/kernel/setup.c). Since we didn't care
about the overhead incurred by interrupt processing, it's not that accurate
though (I get 24.8 MHz on my 25 MHz 68040).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

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?

[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/