Re: 2.5.44: How to decode call trace

Re: 2.5.44: How to decode call trace

[Andi Kleen]

Olaf Dietsche <olaf.dietsche#list.linux-kernel@t-online.de> writes:
> and this is the code:
> static int __fscap_lookup(struct vfsmount *mnt, struct nameidata *nd)
> {
> 	static char name[] = ".capabilities";
> 	nd->mnt = mntget(mnt);
> 	nd->dentry = dget(mnt->mnt_sb->s_root);
> 	nd->flags = 0;
> 	return path_walk(name, nd);
> }
> 
> What does .text.lock.namei and name.810 mean?

.text.lock.namei means that it hung in the slow path of a spinlock that
is referenced from namei.c

name.810 is a static data variable, probably the static char name[]
shown above. Remember the kernel backtrace is not exact and can print
random stack junk that looks like return addresses too. You always have 
to sanity check each entry.

> Is there a way to get the line number out of these hex values?

addr2line -e vmlinux ... does this when you compile the kernel with -g 

-Andi

Re: 2.5.44: How to decode call trace

[bert hubert]

On Wed, Oct 23, 2002 at 05:50:41AM +0200, Andi Kleen wrote:

> > Is there a way to get the line number out of these hex values?
> 
> addr2line -e vmlinux ... does this when you compile the kernel with -g 

Also interesting is http://ds9a.nl/symoops

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

Re: 2.5.44: How to decode call trace

[Olaf Dietsche]

bert hubert <ahu@ds9a.nl> writes:

> On Wed, Oct 23, 2002 at 05:50:41AM +0200, Andi Kleen wrote:
>
>> > Is there a way to get the line number out of these hex values?
>> 
>> addr2line -e vmlinux ... does this when you compile the kernel with -g 
>
> Also interesting is http://ds9a.nl/symoops

This is a real shortcut. Thanks.

Regards, Olaf.

Re: 2.5.44: How to decode call trace

[Olaf Dietsche]

Andi Kleen <ak@suse.de> writes:

> Olaf Dietsche <olaf.dietsche#list.linux-kernel@t-online.de> writes:
>> and this is the code:
>> static int __fscap_lookup(struct vfsmount *mnt, struct nameidata *nd)
>> {
>> 	static char name[] = ".capabilities";
>> 	nd->mnt = mntget(mnt);
>> 	nd->dentry = dget(mnt->mnt_sb->s_root);
>> 	nd->flags = 0;
>> 	return path_walk(name, nd);
>> }
>> 
>> What does .text.lock.namei and name.810 mean?
>
> .text.lock.namei means that it hung in the slow path of a spinlock that
> is referenced from namei.c

I guess this is what __down_failed means.

> name.810 is a static data variable, probably the static char name[]
> shown above. Remember the kernel backtrace is not exact and can print
> random stack junk that looks like return addresses too. You always have 
> to sanity check each entry.

Ok, I'll keep that in mind.

>> Is there a way to get the line number out of these hex values?
>
> addr2line -e vmlinux ... does this when you compile the kernel with -g 

Great! This is what I was searching for.

When I build with "make -k EXTRA_CFLAGS=-g EXTRA_LDFLAGS=-g bzImage",
I get a ton of error messages from drivers/acpi/include/actypes.h and
other acpi related stuff, starting with: #error ACPI_MACHINE_WIDTH not
defined. Maybe this is not the usual way to build with -g, but I don't
get these errors with "make -k bzImage". Maybe someone is interested
in this.

Anyway, I come around this by first building with "EXTRA_CFLAGS=-g
EXTRA_LDFLAGS=-g", ignoring the error messages and then a second try
with only EXTRA_LDFLAGS=-g.

Regards, Olaf.

Re: [ACPI] Re: 2.5.44: How to decode call trace

[Matthew Wilcox]

On Wed, Oct 23, 2002 at 12:33:25PM +0200, Olaf Dietsche wrote:
> When I build with "make -k EXTRA_CFLAGS=-g EXTRA_LDFLAGS=-g bzImage",
> I get a ton of error messages from drivers/acpi/include/actypes.h and
> other acpi related stuff, starting with: #error ACPI_MACHINE_WIDTH not
> defined. Maybe this is not the usual way to build with -g, but I don't
> get these errors with "make -k bzImage". Maybe someone is interested
> in this.

Not really.  Users shouldn't be overriding EXTRA_CFLAGS, it's for the
benefit of various parts of the kernel.  Some other parts of the kernel
you break by doing this:

./arch/i386/mach-generic/Makefile:EXTRA_CFLAGS  += -I../kernel
./drivers/ide/pci/Makefile:EXTRA_CFLAGS := -Idrivers/ide
./drivers/message/fusion/Makefile:EXTRA_CFLAGS += ${MPT_CFLAGS}
./drivers/usb/storage/Makefile:EXTRA_CFLAGS     := -Idrivers/scsi
./fs/smbfs/Makefile:EXTRA_CFLAGS += -DSMBFS_PARANOIA
./fs/xfs/Makefile:EXTRA_CFLAGS +=        -Ifs/xfs -funsigned-char
./sound/oss/emu10k1/Makefile:    EXTRA_CFLAGS += -DEMU10K1_DEBUG

The normal way to do what you want is to edit the Makefile and add -g
directly to CFLAGS.

-- 
Revolutions do not require corporate support.

Re: 2.5.44: How to decode call trace

[Olaf Dietsche]

Matthew Wilcox <willy@debian.org> writes:

> The normal way to do what you want is to edit the Makefile and add -g
> directly to CFLAGS.

Ok, thanks.

Regards, Olaf.