debugging a bootloader

debugging a bootloader

[Carlos Mitidieri]

Dear all,
I have a doubt on the applicability of gdb:
Is it possible to use gdb in connection with the accompanying simulator to 
debug a bootloader (like u-boot) for an arm 
Thank you very much for your attention.

Re: debugging a bootloader

[Daniel Jacobowitz]

On Tue, Dec 06, 2005 at 03:01:37PM +0100, Carlos Mitidieri wrote:
> Dear all,
> I have a doubt on the applicability of gdb:
> Is it possible to use gdb in connection with the accompanying simulator to 
> debug a bootloader (like u-boot) for an arm 
> Thank you very much for your attention.

Probably not; you need a simulator that will provide all the hardware
your boot loader expects.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: debugging a bootloader

[Paul Gilliam]

On Tuesday 06 December 2005 06:02, Daniel Jacobowitz wrote:
> On Tue, Dec 06, 2005 at 03:01:37PM +0100, Carlos Mitidieri wrote:
> > Dear all,
> > I have a doubt on the applicability of gdb:
> > Is it possible to use gdb in connection with the accompanying simulator to 
> > debug a bootloader (like u-boot) for an arm 
> > Thank you very much for your attention.
> 
> Probably not; you need a simulator that will provide all the hardware
> your boot loader expects.
> 
 But you *may* be able to debug *part* of it with the simulator.

But that's just a guess
-=# Paul #=-

Re: debugging a bootloader

[Jim Blandy]

You may want to check out SID: http://sourceware.org/sid/

SID is a simulator framework that lets you build whole-board
simulations by plugging together individual components.  It has CPU
cores for ARM (among others), memory, cache, disk drives, and so on. 
And it can talk to GDB via the remote protocol.

Re: debugging a bootloader

[Carlos Mitidieri]

Hello all,

On Tuesday 06 December 2005 19:16, Paul Gilliam wrote:
> On Tuesday 06 December 2005 06:02, Daniel Jacobowitz wrote:
> > On Tue, Dec 06, 2005 at 03:01:37PM +0100, Carlos Mitidieri wrote:

Thank you.

> > > I have a doubt on the applicability of gdb:
> > > Is it possible to use gdb in connection with the accompanying simulator
> > > to debug a bootloader (like u-boot) for an arm
> > > Thank you very much for your attention.
> >
> > Probably not; you need a simulator that will provide all the hardware
> > your boot loader expects.
>
>  But you *may* be able to debug *part* of it with the simulator.
>
> But that's just a guess
> -=# Paul #=-

I have actually tried to debug u-boot with the arm-eabi-gdb target (therefore 
gdb-6.4) in connection with the simulator. In accord to Paul guesses, it was 
possible to run some part of the code. Unfortunately, the arm-eabi-gdb itself 
went through a seg-fault before any problem could be devised in the u-boot.

I then used gdb (configured as "i586-suse-linux") to look at arm-eabi-gdb, so 
obtaining the following outcome:

Program received signal SIGSEGV, Segmentation fault.
0x081405b8 in get_frame_pc (frame=0x0) at frame.c:1321
1321    frame.c: No such file or directory.
        in frame.c

The steps to reproduce this are as follows:

1. Load arm-eabi-gdb in the gdb
2.  Run arm-eabi.gdb
3. In arm-eabi-gdb issue the commands:
	3.1. (gdb) file u-boot.elf
	3.2. (gdb) target sim
	3.3. (gdb) load
	3.4. (gdb) break start_armboot
	3.5. (gdb) run
	3.6. (gdb) step

repeat "step" a few times, and you get the seg-fault.

If somebody would like to take a look at this, but is not willing to build all 
the required cross tools and bootloader, please let me know and I will 
happily send you the binaries.

As a last remark, I have tried another versions from gdb to build the 
arm-eabi-gdb, and this problem appeared on every one.  Also, many versions of 
the cross tools were tested together, with equal results.

Sincerely
Carl

Re: debugging a bootloader

[Carlos Mitidieri]

Hello, 

On Wednesday 07 December 2005 03:35, you wrote:
> You may want to check out SID: http://sourceware.org/sid/
>
> SID is a simulator framework that lets you build whole-board
> simulations by plugging together individual components.  It has CPU
> cores for ARM (among others), memory, cache, disk drives, and so on.
> And it can talk to GDB via the remote protocol.

Thanks for your suggestion
I will take a look at it.

Best regards,
Carl