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?
next prev parent 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