[okl4-developer] no debugging symbols with gdb

Lukas HANEL lukas.hanel at st.com
Wed Apr 23 01:38:33 EST 2008


Hi Geoffrey

Geoffrey Lee wrote:
> On Tue, Apr 22, 2008 at 03:20:16PM +0200, Lukas HANEL wrote:
>   
>> Hi
>>
>> Since I was able to compile OKL4 with my own platform, I am now trying
>> to start/boot OKL4. As I get no output on the serial line, despite
>> having adopted the driver and some memory mappings, I am starting to debug.  Therefore in a first setup I use qemu with gdb. My problem is,
>> that gdb does not find the symbol table in the image.boot file. In the
>> kernel binary it finds the symbol table, but after the elfweaving, the
>> symbol table is not found by gdb.
>> Do you have any hints to solve this problem?

>> There is a symbol table in image.boot, but would guess it would not
>> be suitable for tools like gdb at this stage currently.  For one thing,
>> we munge the name of the OKL4 application into the symbol.  I would
>> suggest you debug with the individual binaries.  Anyway, you can 
>> get the symbol table with the -x flag in objdump(1).
>>     
Actually also objdump wouldn't give me source code on the image.boot,
neither.

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?


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




More information about the Developer mailing list