Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Luis Machado <lgustavo@codesourcery.com>
To: James Bowman <james.bowman@ftdichip.com>,
	"gdb@sourceware.org"	<gdb@sourceware.org>
Subject: Re: Harvard architecture and gdb
Date: Wed, 13 Jan 2016 13:34:00 -0000	[thread overview]
Message-ID: <5696526C.8000307@codesourcery.com> (raw)
In-Reply-To: <CA9BBF0458F83C4F9051448B941B57D12208FB58@glaexch3>

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 
program.

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?


  reply	other threads:[~2016-01-13 13:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-13  3:32 James Bowman
2016-01-13 13:34 ` Luis Machado [this message]
2016-01-13 18:06 duane

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5696526C.8000307@codesourcery.com \
    --to=lgustavo@codesourcery.com \
    --cc=gdb@sourceware.org \
    --cc=james.bowman@ftdichip.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox