RE: kgdb on EM64T

RE: kgdb on EM64T

[Wilkerson, Bryan P]

George Anzinger [mailto:george@mvista.com] wrote:
>
>Well, I checked, it is "int $3".  Why then the panic?  If you try the
>boot with kgdb (i.e. wait) and the do:
>(gdb) disass gdb_interrupt
>What do you find at +75?

Below is the console from the session it is interesting that gdb is not
able to access the memory.   I let it continue and then ctrl-c broke it
later in the boot cycle and tried disass again with the same result.

Feel free to flog me if this is stupid but I have just one EM64T machine
(test) and I'm using a regular P4 machine as dev.  I build the test
kernel on the EM64T machine and then copy the updated sources, object
files, and images via NFS to the dev machine.  I believe I read in the
kgdb doc that it was possible to use to different architecture machines
for test and dev although there wasn't any information about how to do
it.  This is probably the source of the OS/ABI warning.  I can probably
get the mothership to send me another EM64T machine if need be.  

vincent:/home/bwilkers/proj/linux-2.6.13-rc4-mm1 # gdb vmlinux
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i586-suse-linux"...
warning: A handler for the OS ABI "GNU/Linux" is not built into this
configuration
of GDB.  Attempting to continue with the default i386:x86-64 settings.

Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
0x80503b50 in ?? ()
warning: no shared library support for this OS / ABI
(gdb) disass gdb_interrupt
Dump of assembler code for function gdb_interrupt:
0xffffffff80247009 <gdb_interrupt+0>:   Cannot access memory at address
0x80247009
(gdb) c
Continuing.
Bootdata ok (command line is root=/dev/sda2 kgdb console=kgdb)
Linux version 2.6.13-rc4-mm1-perfmon-em64t (bwilkers@jules) (gcc version
3.3.5 20050117 (prerelease) (SUSE Linux)) #43 SMP Sat Aug 27 15:56:14
MDT 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003fe2f800 (usable)
 BIOS-e820: 000000003fe2f800 - 000000003fe3f832 (ACPI NVS)
 BIOS-e820: 000000003ff10000 - 000000003ff30000 (reserved)
 BIOS-e820: 000000003ff30000 - 000000003ff40000 (ACPI data)
 BIOS-e820: 000000003ff40000 - 000000003fff0000 (ACPI NVS)
 BIOS-e820: 000000003fff0000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fed13000 - 00000000fed1a000 (reserved)
 BIOS-e820: 00000000fed1c000 - 00000000feda0000 (reserved)
ACPI: PM-Timer IO Port: 0x408
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)

Re: kgdb on EM64T

[George Anzinger]

Wilkerson, Bryan P wrote:
> 
> George Anzinger [mailto:george@mvista.com] wrote:
> 
>>Well, I checked, it is "int $3".  Why then the panic?  If you try the
>>boot with kgdb (i.e. wait) and the do:
>>(gdb) disass gdb_interrupt
>>What do you find at +75?
> 
> 
> Below is the console from the session it is interesting that gdb is not
> able to access the memory.   I let it continue and then ctrl-c broke it
> later in the boot cycle and tried disass again with the same result.
> 
> Feel free to flog me if this is stupid but I have just one EM64T machine
> (test) and I'm using a regular P4 machine as dev.  I build the test
> kernel on the EM64T machine and then copy the updated sources, object
> files, and images via NFS to the dev machine.  I believe I read in the
> kgdb doc that it was possible to use to different architecture machines
> for test and dev although there wasn't any information about how to do
> it.  This is probably the source of the OS/ABI warning.  I can probably
> get the mothership to send me another EM64T machine if need be.  

What you need is a cross development environment.  Not having that, your 
gdb is likely not aware of how to talk to the hardware you are using. 
The cross develoment should cost a whole lot less than another machine.

George
-- 
> 
> vincent:/home/bwilkers/proj/linux-2.6.13-rc4-mm1 # gdb vmlinux
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "i586-suse-linux"...
> warning: A handler for the OS ABI "GNU/Linux" is not built into this
> configuration
> of GDB.  Attempting to continue with the default i386:x86-64 settings.
> 
> Using host libthread_db library "/lib/tls/libthread_db.so.1".
> 
> (gdb) target remote /dev/ttyS0
> Remote debugging using /dev/ttyS0
> 0x80503b50 in ?? ()
> warning: no shared library support for this OS / ABI
> (gdb) disass gdb_interrupt
> Dump of assembler code for function gdb_interrupt:
> 0xffffffff80247009 <gdb_interrupt+0>:   Cannot access memory at address
> 0x80247009
> (gdb) c
> Continuing.
> Bootdata ok (command line is root=/dev/sda2 kgdb console=kgdb)
> Linux version 2.6.13-rc4-mm1-perfmon-em64t (bwilkers@jules) (gcc version
> 3.3.5 20050117 (prerelease) (SUSE Linux)) #43 SMP Sat Aug 27 15:56:14
> MDT 2005
> BIOS-provided physical RAM map:
>  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
>  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
>  BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved)
>  BIOS-e820: 0000000000100000 - 000000003fe2f800 (usable)
>  BIOS-e820: 000000003fe2f800 - 000000003fe3f832 (ACPI NVS)
>  BIOS-e820: 000000003ff10000 - 000000003ff30000 (reserved)
>  BIOS-e820: 000000003ff30000 - 000000003ff40000 (ACPI data)
>  BIOS-e820: 000000003ff40000 - 000000003fff0000 (ACPI NVS)
>  BIOS-e820: 000000003fff0000 - 0000000040000000 (reserved)
>  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
>  BIOS-e820: 00000000fed13000 - 00000000fed1a000 (reserved)
>  BIOS-e820: 00000000fed1c000 - 00000000feda0000 (reserved)
> ACPI: PM-Timer IO Port: 0x408
> ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

kgdb on EM64T

[Wilkerson, Bryan P]

Thanks you Tom and George for the tips on using kgdb with
2.6.13-rc4-mm1.  

I almost have it working but kgdb seems to have a few issues.  I can get
it running from the dev machine using the kgdb and console=kgdb boot
options on the test kernel.  The kernel waits as it should and when I
attach with "target remote /dev/ttyS0" and I can continue the boot but
eventually it gets to a point in the boot where it frees unused kernel
memory successfully and then a warning, "unable to open an initial
console",  followed by, "Kernel panic - not syncing: Attempted to kill
init!"

Removing the console=kgdb boot option and the machine boots all the way
to run level 5.   I tried to break into kgdb at this point using the 
	$echo -e "\003" > /dev/ttyS0
from the dev machine but the test kernel panics at gdb_interrupt+75 when
it receives anything on the serial port.  Hmmm...

I'm wondering if I'm maybe just the first to try this on EM64T (kernel
builds in the arch/x86_64 tree).   

Any suggestions welcome.

-bryan

Re: kgdb on EM64T

[George Anzinger]

Wilkerson, Bryan P wrote:
> Thanks you Tom and George for the tips on using kgdb with
> 2.6.13-rc4-mm1.  
> 
> I almost have it working but kgdb seems to have a few issues.  I can get
> it running from the dev machine using the kgdb and console=kgdb boot
> options on the test kernel.  The kernel waits as it should and when I
> attach with "target remote /dev/ttyS0" and I can continue the boot but
> eventually it gets to a point in the boot where it frees unused kernel
> memory successfully and then a warning, "unable to open an initial
> console",  followed by, "Kernel panic - not syncing: Attempted to kill
> init!"
> 
> Removing the console=kgdb boot option and the machine boots all the way
> to run level 5.   I tried to break into kgdb at this point using the 
> 	$echo -e "\003" > /dev/ttyS0
> from the dev machine but the test kernel panics at gdb_interrupt+75 when
> it receives anything on the serial port.  Hmmm...
> 
> I'm wondering if I'm maybe just the first to try this on EM64T (kernel
> builds in the arch/x86_64 tree).   

Possibly:).  Since the serial port seems to work (i.e. the first test 
above), the fault seems to be in handling the int3.  Is int3 the right 
instruction for this machine?  If not you would make the change in 
kgdb.h.  I think that is the only place it is defined.
> 
-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

Re: kgdb on EM64T

[George Anzinger]

George Anzinger wrote:
> Wilkerson, Bryan P wrote:
> 
>> Thanks you Tom and George for the tips on using kgdb with
>> 2.6.13-rc4-mm1. 
>> I almost have it working but kgdb seems to have a few issues.  I can get
>> it running from the dev machine using the kgdb and console=kgdb boot
>> options on the test kernel.  The kernel waits as it should and when I
>> attach with "target remote /dev/ttyS0" and I can continue the boot but
>> eventually it gets to a point in the boot where it frees unused kernel
>> memory successfully and then a warning, "unable to open an initial
>> console",  followed by, "Kernel panic - not syncing: Attempted to kill
>> init!"
>>
>> Removing the console=kgdb boot option and the machine boots all the way
>> to run level 5.   I tried to break into kgdb at this point using the 
>>     $echo -e "\003" > /dev/ttyS0
>> from the dev machine but the test kernel panics at gdb_interrupt+75 when
>> it receives anything on the serial port.  Hmmm...
>>
>> I'm wondering if I'm maybe just the first to try this on EM64T (kernel
>> builds in the arch/x86_64 tree).   
> 
> 
> Possibly:).  Since the serial port seems to work (i.e. the first test 
> above), the fault seems to be in handling the int3.  Is int3 the right 
> instruction for this machine?  If not you would make the change in 
> kgdb.h.  I think that is the only place it is defined.

Well, I checked, it is "int $3".  Why then the panic?  If you try the 
boot with kgdb (i.e. wait) and the do:
(gdb) disass gdb_interrupt
What do you find at +75?
> 
>>

-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/