Determining the stack and heap address ranges using gdb

[Joel Sherrill]

On 6/3/2014 9:50 AM, Martin Galvan wrote:
> 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)
>
Oh... That macro is clearly out of date for 4.11. The C Program heap and
workspace directly
use the SuperCore Heap now with an allocator mutex.

The answer to the question depends on what you really want to know.
Walking the
heap doesn't help that much. There are malloc statistics you can use but
RTEMS doesn't
use the C Program Heap. By default, there is an OS area and C Program
Heap for
malloc/free.

The reserved area for RTEMS is calculated by confdefs.h for any application.
In gdb, this works to show that:

(gdb) p Configuration
$1 = {work_space_size = 12352, stack_space_size = 8272,

> 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.
>
I am on travel so slow. Hotel wifi was even out a lot of yesterday.

The macros are just helpers and ideally would be replaced by Python
pretty printers.
They are not high on the maintenance list and if you want to help get
them working
again, jump in. They were all created out of necessity by someone
wanting to see
something.
> 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?
I added stack base and size to the rtems_tasks command. You need to get
the macrosfrom git.
> 2) If the script I looked at really is outdated (it was last updated
> on 2008), where can I find the current one?
The comment at the top is old but git shows it had a commit last year.
I just committed a patch to delete the junk comments and add stack
base/size.

The heap part is left as an exercise.

> 3) What's the reason for using that hardcoded 0xffff in rtems_malloc_walk?
Probably because the "index" must be < 64K and someone wanted to be sure.
> 4) Is there any documentation on those structures and data types, such
> as _Region_Information?
>
All of the data structures and code inside RTEMS are well documented using
Doxygen. The output is generated twice a day.

http://www.rtems.org/onlinedocs/doxygen/cpukit/html/

If you see something confusing, missing, or wrong, just ask or suggest a
patch.
> Any info will be appreciated. Thanks a lot!

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985