[llvm-dev] DWARF .debug_aranges data objects and address spaces

[David Blaikie via llvm-dev]

On Wed, Mar 11, 2020 at 8:09 AM Luke Drummond <luke.drummond at codeplay.com>
wrote:

> On Tue Mar 10, 2020 at 7:45 PM, David Blaikie wrote:
> > If you only want code addresses, why not use the CU's
> > low_pc/high_pc/ranges
> > - those are guaranteed to be only code addresses, I think?
> >
> In the common case, for most targets LLVM supports I think you're right,
> but for my case, regrettably, not. Because my target is a Harvard
> Architecture, any code address can have the same ordinal value as any
> data address: the code and data reside on different buses so the whole
> 4GiB space is available to both code, and data. `DW_AT_low_pc` and
> `DW_AT_high_pc` can be used to find the range of the code segment, but
> given an arbitrary address, cannot be used to conclusively determine
> whether that address belongs to code or data when both segments contain
> addresses in that numeric range.


Sorry I'm not following, partly probably due to my not having worked with
such machines before.

But how are the code addresses and data addresses differentiated then (eg:
if you had segment selectors in debug_aranges, how would they be used? The
addresses taken from the system at runtime have some kind of segment
selector associated with them, that you can then use to match with the
addr+segment selector in aranges?).

Actually, coming at it from a different angle: It sounds like in the
original email you're suggesting if debug_aranges did not contain data
addresses, this would be good/sufficient for you? So somehow you'd be
ensuring you only query debug_aranges using things you know are code
addresses, not data addresses? So why would the same solution/approach not
hold to querying low/high/ranges on a CU that's already guaranteed not to
contain data addresses?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200312/16d831ef/attachment.html>