Determining the stack and heap address ranges using gdb

[Martin Galvan]

Hi everyone! I'm currently doing a bit of research on RTEMS and gdb, and
I'm having a bit of trouble understanding the way it all works. Right now I
need a way to determine the address ranges of the stack and heap of a given
C program using gdb. I'm aware there are some tips in
http://www.rtems.org/wiki/index.php/Debugging, but they themselves admit
those are really crude estimates. They do mention there's probably some way
to do a stack/heap walk using gdb scripts, but even with the Python API I'm
clueless as how to do it.

I contacted Joel Sherrill about this, and he told me to look at
rtems-testing/sim-scripts and check out the gdb macro files. I looked at
this file:

http://git.rtems.org/rtems-testing/tree/sim-scripts/rtems-gdb-macros-4.11

which contains a macro called rtems_malloc_walk, that does the following:

(((Region_Control
*)_Region_Information->local_table[RTEMS_Malloc_Heap&0xffff])->Memory)

However, when I showed it to Joel he told me it must be an old version
since Malloc hasn't used a region in a while. I asked him where I could get
a current version (which is sort of weird because I thought 4.11 is the
latest), but he hasn't answered yet.

With all this, I have a few questions:

1) Is there any way to get that kind of info on the threads' stacks, the
RTEMS workspace and the heap, besides what's done in the gdb scripts?
2) If the script I looked at really is outdated (it was last updated on
2008), where can I find the current one?
3) What's the reason for using that hardcoded 0xffff in rtems_malloc_walk?
4) Is there any documentation on those structures and data types, such as
_Region_Information?

Any info will be appreciated. Thanks a lot!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20140603/e6c4188b/attachment.html>