Putting debug info in rtems files

[Smith, Gene]

Smith, Gene wrote, On 10/11/2004 8:44 AM:

> Thomas Doerfler wrote, On 10/11/2004 1:24 AM:
> 
>>Gene,
>>
>>when RTEMS libraries get built, nested makefiles are 
>>executed that "walk" through the build directory 
>>structure. Therefore, each file is compiled from a 
>>certain point in the build directory structure that 
>>lies in paralllel to the source directory structure.
> 
> 
> Yeah, that's what I finally figured out too *after* I posted. It's based 
> on the "build-rtems" directory structure.
> 
> 
>>Consequeces:
>>- You have more or less of these "dots" depending on 
>>how deep the corresponding directory is inside the 
>>build tree. Just an idea: You might come around 
>>this, if you call the initial "configure" not in a 
>>relative way (e.g. "../rtems-4.6.0/configure", but 
>>in an absolute way, e.g. 
>>"/usr/local/src/rtems/tools/rtems-4.6.0/configure").
> 
> 
> That sounds promising. Thanks.

Running configure absolute didn't help. Still had dots in runtime file. 
What I ended up doing was moving "build-rtems" from out of my home 
directory to the root level (and making me the owner) and building from 
there. That way most file paths in the r.t. file are absolute with no 
../ so the default "directory" in gdb works. Can set a directory path in 
gdb to pick up some .inl (inline) files in /opt/rtems-4.6 install area. 
So on cygwin I am able to run insight/gdb and debug source contained on 
the linux box. I did have some "issues" with gdb which are discussed on 
the insight mail list but it seems to be working find, debug wise, now.

> 
> 
>>- There is no common location, from which the source 
>>file pointers in the debug info is correct for all 
>>object files.
>>
>>wkr,
>>Thomas.
>>
>>
>>
>>
>>>Kamen Penev wrote, On 10/08/2004 08:47 PM:
>>>
>>>
>>>>My intuition is this is a linker problem. Check your linker script and 
>>>>the invocation of the linker. Make sure you are not throwing away the 
>>>>stabs sections.
>>>>
>>>>Kamen
>>>>
>>>
>>>My linkcmds file (based on helas403) does call out the stab sections (as 
>>>well as dwarfs).
>>>
>>>I noticed that when I run gdb (via insight) I can actually see my source 
>>>if I set my gdb source "directory" path just right. This seems to be 
>>>because there are a lot of "../" constructs in the hello.exe file. For 
>>>example I see things like this where source files appear in the binary:
>>>
>>>../../../../../../rtems-4.6.1/cpukit/libcsupport/src/malloc.c
>>>
>>>../../../../../rtems-4.6.1/c/src/optman/rtems/no-dpmem.c
>>>
>>>../../../../../../../../../rtems-4.6.1/c/src/lib/libcpu/powerpc/ppc403/console/console405.c
>>>
>>>I see the same things when files are entered when running gdb.
>>>
>>>The number of ../'s seem to depend on something since they vary with 
>>>file but not sure what. Any idea what controls this? (I have to set my 
>>>"directory" possibly 9, 5, 6 levels beyond the "rtems-4.6.1" to see my 
>>>source in gdb.)
>>>
>>>If the ../'s weren't there, I could set my gdb directory to right before 
>>>the "rtems-4.6.1" and gdb would append to that the correct file path. 
>>>Anyone know what is going on here and if it is possible to get rid of 
>>>the ../'s?
>>>
>>>-gene
>>
>>
>>--------------------------------------------
>>IMD Ingenieurbuero fuer Microcomputertechnik
>>Thomas Doerfler           Herbststrasse 8
>>D-82178 Puchheim          Germany
>>email:    Thomas.Doerfler at imd-systems.de
>>PGP public key available at: http://www.imd-
>>systems.de/pgp_keys.htm
>>
> 
>