Harvard architecture and gdb

Luis Machado lgustavo@codesourcery.com
Wed Jan 13 13:34:00 GMT 2016

On 01/13/2016 01:32 AM, James Bowman wrote:
> I am maintainer for a Harvard architecture target, FT32.
> FT32 has two address spaces, flash and RAM. They both occupy addresses starting at address 0. This is similar to AVR. We use a __flash__ modifier to specify address space 1.
> But I am struggling to understand how to describe the architecture to gdb. In particular FT32 uses address spaces to distinguish between pointers to RAM and flash. But gdb only seems to actually care about address spaces for *pointers*. When gcc writes the debug info for a plain object, it does not emit the DW_AT_address_class field; nor does gdb handle DW_AT_address_class for non-pointer types.  So I am at a loss to understand how these two variables would be distinguished by gdb:
>    int ram_var = 1234;
>    __flash__ const int flash_var = 1234;

Right now, they wouldn't be distinguished.

> I suspect I have misunderstood something fundamental. Does anyone have any suggestions? Thanks.

Though supported by DWARF by means of DW_AT_address_class and also 
DW_AT_segment, this is not readily available in GDB right now.

On the compiler's side, it needs to be adjusted to provide enough debug 
information about those address spaces for each object being used in the 

On GDB's side, the DWARF machinery and other bits need to be expanded to 
not assume a single address space and new hooks need to be added to 
handle reading data properly from those address spaces.

One limitation of GDB in this regard is assuming there are only a couple 
basic pointer types: data and code. Some architectures may have two 
distinct code pointers of different sizes, for example. So GDB needs to 
be able to tell when/how to use each.

Assuming the compiler and GDB are augmented to understand those, then 
the DWARF machinery in GDB can call the correct hooks to either read or 
write from/to flash or RAM.

Does this bring some light to your problem?

More information about the Gdb mailing list