[okl4-developer] no debugging symbols with gdb

[Lukas HANEL]

Hi Nelson,

I figured that out on my own, even though I made some detour:

When using the actual binary to boot, I run into problems with the
Kernel starting at address 0xf0000000. So I used objcopy
--change-addresses -0xXXXXXXXX to forge the kernel to start in my
physical memory. That way I was able to run the kernel, but it did not
finish the startup. As I figured out, the problem arises from a switch
statement, which was transformed into a series of absolute jumps. As
these addresses were not changed by objcopy, shortly after such a jump,
the kernel crashed.

I tried then to boot the image.boot and use gdb with the original kernel
binary and that worked.

As the kernel starts on physical addresses gdb could not use the
standard kernel image. So I use my objcopied binary for the first phase
of kernel startup. Afterwards I add the original kernel image with
add-symbol-file to gdb. And that way I can continue.

Lukas

Nelson Tam wrote:
> 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?
>
> -- 
> (nt)
>
> Nelson Tam
>