[okl4-developer] no debugging symbols with gdb

Nelson Tam nelson at ok-labs.com
Tue Apr 29 22:48:10 EST 2008


Hi Lukas,

May I suggest a slightly different approach here:

When elfweaver generates the final image.elf for execution, debugging  
symbols are stripped.  However if you know what the faulting  
instruction pointer is, you can still find out which function it  
corresponds to.  First, do

   $ readelf -a build/image.elf

by finding the section that the faulting ip corresponds to, you will  
get the name of the binary that contains the faulting function.  This  
binary is not stripped.  I'm not too familiar with gdb, but perhaps  
you could tell it to find debugging symbols from this binary instead?

On 23/04/2008, at 1:38 AM, Lukas HANEL wrote:
>
> 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.
>

--
(nt)

Nelson Tam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1560 bytes
Desc: not available
Url : http://lists.okl4.org/pipermail/developer/attachments/20080429/83228fd1/attachment.bin 


More information about the Developer mailing list