[okl4-developer] no debugging symbols with gdb

[Geoffrey Lee]

On Tue, Apr 22, 2008 at 05:38:33PM +0200, Lukas HANEL wrote:
> Hi Geoffrey
> 

Hi Lukas

> >>     
> Actually also objdump wouldn't give me source code on the image.boot,
> neither.

In general it is better to rely on the actual individual binaries to 
get debug information.  image.boot should be used for booting.

> 
> Trying to debug with the actual binary I get a memory access violation
> in qemu, because the kernel code starts at 0xf0000000, which is not a
> valid address in my machine.
> 
> Using objcopy --change-addresses I adjusted the address, so I can start
> start the kernel without immediate crash. Where can I adjust these
> addresses in Scons, to automatically build a useful kernel binary?
> 
> Using the actual binary, I have some more information, however, gdb is
> still restricted because it has no line information in the binary. How
> can I tell scons to add line information in the binary?
> 
> Do you have any tricks for handling the switch between physical and
> virtual addresses in gdb/general debugging?

The kernel doesn't actually start 0xf0000000.  It starts to run at a
physical address, then it switches the MMU on and the kernel is
remapped into the virtual address space.  The virtual address space
should be clean.  Are you planning to map something there yourself?

Personally I don't use gdb for debugging, so I probably cannot offer
useful advice here.

	-gl

> 
> 
> > Hi 
> >
> >
> > At the moment the kernel has a separate serial driver for 
> > debugging purpose.  Iguana also has a user-level serial driver.
> > Which driver are you having trouble starting?
> >   
> I think it is not necessarily a problem with the serial driver. I run
> the kernel on a new platform and did not yet adopt it enough. So when I
> run the simulation, after a while the CPU does not advance from
> 0xffff000c. So my approach was to follow the startup and try to find
> something odd.
> 
> Also in the meanwhile I am only using l4 with l4test, so no big userland
> with drivers.
> 
> Thanks,
> Lukas
> 
> 
> >> Apart from that I am able to do assembler based debugging with the
> >> objdumped binary in a second window. But this is obviously much slower
> >> and less convenient.
> >>
> >> Thanks,
> >> Lukas Hänel
> >>
> >> Setup:
> >>
> >> qemu
> >>
> >> ~$ /usr/bin/qemu-system-arm -kernel okl4_2.1/build/images/image.boot -M versatilepb -nographic -serial stdio -s -S
> >>
> >>
> >> Codesourcery gdb
> >>
> >> ~/okl4_2.1$ arm-2005q3-2-arm-none-eabi-i686-pc-linux-gnu/bin/arm-none-eabi-gdb build/images/image.boot 
> >>
> >> GNU gdb 6.3.50.20051020-cvs
> >>
> >> 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 "--host=i686-pc-linux-gnu --target=arm-none-eabi"...
> >>
> >> (no debugging symbols found)
> >>
> >> (gdb) 
> >>
> >>
> >> However, when using the kernel binary directly, I have interesting output:
> >>
> >> ~/okl4_2.1$ /mnt/nfs/arm/arm-2005q3-2-arm-none-eabi-i686-pc-gnu/bin/arm-none-eabi-gdb build/pistachio/bin/kernel -silent 
> >>
> >> (gdb) info functions
> >>
> >> All defined functions:
> >>
> >> File pistachio/src/asid.cc:
> >>
> >> static 
> >>
> >>     void global constructors keyed to pistachio_src_asid.cc_BCB13488_55898A01(void);
> >>
> >> File pistachio/src/assert.cc:
> >>
> >> void __assert_failure(char const*);
> >>
> >> File pistachio/src/cache.cc:
> >>
> >> ...
> >>
> >> As you do not use any strip commands, objdump obviously shows the symbol
> >> tables in both files.
> >>
> >>
> >> _______________________________________________
> >> Developer mailing list
> >> Developer at okl4.org
> >> https://lists.okl4.org/mailman/listinfo/developer
> >>
> >>     
> >
> >   
> 
> 

--