Re: [lldb-dev] lldb versus visual studio

[Zdenek Prikryl via lldb-dev]

LLVM-MI, that can be used in Eclipse, lives here [1] and it is still in 
use. Although more people working on it would be definitely better 
situation that it is at the moment :-)...


[1] https://github.com/lldb-tools/lldb-mi

*Zdenek Prikryl* | /CTO/ | +420 541 141 475 | www.codasip.com 




On 3/22/21 10:31 PM, Franz Fehringer via lldb-dev wrote:

Thx again


Am 22.03.2021 um 21:55 schrieb Ted Woodward:

There was. Almost nobody used it. Nobody maintained it.


-Original Message-
From: lldb-dev  On Behalf Of Franz
Fehringer via lldb-dev
Sent: Monday, March 22, 2021 2:28 PM
To: lldb-dev@lists.llvm.org
Subject: [EXT] Re: [lldb-dev] lldb versus visual studio

Thank you very much, this essentially meets my expectations (no eclipse
debugging with Windows/VC++), i am a little surprised that there is no
working lldb integration for eclipse, is this really the whole truth 
(or did i

misunderstand)?


Am 22.03.2021 um 19:28 schrieb Greg Clayton:

On Mar 20, 2021, at 8:57 AM, Franz Fehringer via lldb-dev 
d...@lists.llvm.org> wrote:

Dear lldb-dev community,

First a disclaimer: If my question is inappropriate for this 
(developer) list
please ignore or guide me to a more appropriate list (it is possibly 
more of an

end user question).

Is it possible to debug Visual Studio generated (with pdb debug info)

executables (2017 or 2019, C++ only)  with lldb?

LLDB does have PDB parsing abilities, though I am unsure how well they
work out of the box with no extra configuration. There are two PDB 
parsers
in LLDB at the moment, one that uses a DLL from Visual Studio that 
knows
how to parse a PDB file, and one that tries to parse the PDB file 
manually. So
if you are natively on windows, I believe you might need to set run 
the batch
file that sets up environment variables for finding these DLLs. The 
native PDB
parser should work, but I am not sure if the native version always 
takes

precedence when running on the Windows OS.

Maybe someone that did the PDB integration could chime in?


And if so is there a full integration into eclipse so i can debug 
Visual Studio

generated executable with eclipse?
The only integration that I am aware of was one that used lldb-mi, 
or the
GDB remote machine interface. But the lldb-mi was dropped from the 
top of

tree LLDB a while ago because it was not tested and was bit rotting.

We do have a lldb-vscode binary that implements the Microsoft Visual
Studio Code DAP (Debug Adaptor Protocol). If there are any Eclipse 
plug-ins
that integrated with the VS Code DAP plug-ins, that would be the 
option I
would suggest looking into. Is using Visual Studio Code an option, 
or only

Eclipse?

The platform in question is Microsoft Windows 10 (recent versions).

Thx in advance

Franz

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [RFC] Segmented Address Space Support in LLDB

[Zdenek Prikryl via lldb-dev]

On 11/10/20 10:01 PM, Jonas Devlieghere wrote:

On Nov 10, 2020, at 12:58 PM, Zdenek Prikryl  wrote:

Hi all,

Just for the record, we have successfully implemented the wrapping of addr_t 
into a class to support multiple address spaces. The info about address space 
is stored in the ELF file, so we get the info from ELF parser and then pass it 
to the rest of the system. CLI/MI interface has been extended as well, so user 
can select with address space he wants for memory printing. Similarly, we 
patched expression evaluation, disassembler, etc.

That's really interesting, I'm excited to hear that this is feasible and has 
been done before. Is this code available publicly and/or is this something 
you'd be willing to upstream (with our help)?


The code is not available at public repository, but we're more than 
happy to work on/help with the new proposal and share our findings or 
code snippets.


--
Zdenek Prikryl
CTO
T +420 541 141 475
Codasip.com

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [RFC] Segmented Address Space Support in LLDB

[Zdenek Prikryl via lldb-dev]

Hi all,

Just for the record, we have successfully implemented the wrapping of 
addr_t into a class to support multiple address spaces. The info about 
address space is stored in the ELF file, so we get the info from ELF 
parser and then pass it to the rest of the system. CLI/MI interface has 
been extended as well, so user can select with address space he wants 
for memory printing. Similarly, we patched expression evaluation, 
disassembler, etc.


If the address wrap is part of the upstream version, it will be awesome 
:-)...


Best regards.

On 10/20/20 9:30 PM, Ted Woodward via lldb-dev wrote:

I agree with Pavel about the larger picture - we need to know the driver behind 
address spaces before we can discuss a workable solution.

I've dealt with 2 use cases - Harvard architecture cores, and low level 
hardware debugging.

A Harvard architecture core has separate instruction and data memories. These often use 
the same addresses, so to distinguish between them you need address spaces. The Motorola 
DSP56300 had 1 program and 2 data memories, called p, x and y. p:100, x:100 and y:100 
were all separate memories, so "address 100" isn't enough to get what the user 
needed to see.

For low level hardware debugging (often using JTAG), many devices let you access memories in ways like 
"virtual using the TLB", or "virtual == physical, through the core", or "physical, 
through the SoC, not cached". Memory spaces, done right, can give the user the flexibility to pick how 
to view memory.


Are these the use cases you were envisioning, Jonas?


-Original Message-
From: lldb-dev  On Behalf Of Pavel Labath
via lldb-dev
Sent: Tuesday, October 20, 2020 12:51 PM
To: Jonas Devlieghere ; LLDB 
Subject: [EXT] Re: [lldb-dev] [RFC] Segmented Address Space Support in
LLDB

There's a lot of things that are unclear to me about this proposal. The
mechanics of representing an segmented address are one thing, but I I think
that the really interesting part will be the interaction with the rest of lldb. 
Like
- What's going to be the source of this address space information? Is it going
to be statically baked into lldb (a function of the target architecture?), or
dynamically retrieved from the target or platform we're debugging? How
would that work?
- How is this going to interact with Object/SymbolFile classes? Are you
expecting to use existing object and symbol formats for address space
information, or some custom ones? AFAIK, none of the existing formats
actually support encoding address space information (though that hasn't
stopped people from trying).

Without understanding the bigger picture it's hard for me to say whether the
proposed large scale refactoring is a good idea. Nonetheless, I am doubtful of
the viability of that approach. Some of my reasons for that are:
- not all addr_ts represent an actual address -- sometimes that is a difference
between two addresses, which still uses addr_t, as that's guaranteed to fit.
- relatedly to that, there is a difference (I'd expect) between the operations
supported by the two types. addr_t supports all integral operations (though I
hope we don't use all of them), but I wouldn't expect to be able to do the
same with a SegmentedAddress. For one, I'd expect it wouldn't be possible
to add two SegmentedAddresses together (which is possible for addr_t).
OTOH, adding a SegmentedAddress and an addr_t would probably be fine?
Would subtracting two SegmentedAddresses should result in an addr_t? But
only if they have matching address spaces (and assert otherwise)?
- I'd also be worried about over-generalizing specialized code which can
afford to work with plain addresses, and where the added address space
would be a nuisance (or a source of bugs). E.g. ELF has no notion of address
space, so I don't think I'd find it helpful to replace all plain integer 
calculations
in elf parsing code with something more complex.
(I'm aware that some people are using elf to encode address space
information, but this is a pretty nonstandard extension, and it'd take more
than type substitution to support anything like that.)
- large scale refactorings are very much not the norm in llvm



On 19/10/2020 23:56, Jonas Devlieghere via lldb-dev wrote:

We want to support segmented address spaces in LLDB. Currently, all of
LLDB’s external API, command line interface, and internals assume that
an address in memory can be addressed unambiguously as an addr_t (aka
uint64_t). To support a segmented address space we’d need to extend
addr_t with a discriminator (an aspace_t) to uniquely identify a
location in memory. This RFC outlines what would need to change and
how we propose to do that.

### Addresses in LLDB

Currently, LLDB has two ways of representing an address:

   - Address object. Mostly represents addresses as Section+offset for
a binary image loaded in the Target. An Address in this form can
persist across executions, e.g. an address breakpoint in a binary
image that loads at a different address 

Re: [lldb-dev] [RFC] Removing lldb-mi

[Zdenek Prikryl via lldb-dev]

We're using it with Eclipse and Eclipse based product, so I'd like to 
keep as well! :-)...


Zdenek

On 7/2/19 12:21 AM, Ted Woodward via lldb-dev wrote:


We’re using lldb-mi to debug with Eclipse in the Hexagon SDK. I’d 
really like to keep it! 


Ted

*From:* lldb-dev  *On Behalf Of 
*Jonas Devlieghere via lldb-dev

*Sent:* Monday, July 1, 2019 5:09 PM
*To:* LLDB 
*Subject:* [EXT] [lldb-dev] [RFC] Removing lldb-mi

Hi everyone,

After long consideration, I want to propose removing lldb-mi from the 
repository. It is basically unmaintained, doesn't match the LLDB code 
style, and worst of all the tests are unreliable if not already 
disabled. As far as I can tell it's missing core functionality to be 
usable from something like say emacs.


Thanks,

Jonas


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Are overlapping ELF sections problematic?

[Zdenek Prikryl via lldb-dev]

Hi Pavel, Thomas,

Just a note that this topic is repeating now and then. It'd be nice to 
have a concept at least. We can go with an additional argument, or 
enhance addr_t, or enhance Address, or create a new type for it. So, 
some sort of discussion that would clarify the concept a little bit is 
welcome, I think.


Best regards.

On 6/3/19 1:21 PM, Pavel Labath via lldb-dev wrote:

On 03/06/2019 10:19, Thomas Goodfellow via lldb-dev wrote:

I'm working with an embedded platform that segregates memory between
executable code, RAM, and constant values. The three kinds occupy
three separate address spaces, accessed by specific instructions (e.g.
"load from RAM address #0" vs "load from constant ROM address #0")
with fairly small ranges for literal address values. So necessarily
all three address spaces all start at zero.

We're using the LLVM toolchain with ELF32 files, mapping the three
spaces as.text, .data, and .crom sections, with a linker script
setting the address for all three sections to zero and so producing a
non-relocatable executable image (the .text section becomes a ROM for
an embedded device so final addresses are required). To support
debugging with LLDB (where the GDB server protocol presumes a single
flat memory space) the sections are mapped to address ranges in a
larger space (using the top two bits) and the debugger stub of the
platform then demuxes the memory accesses to the appropriate address
spaces).

Until recently this was done by loading the ELF file in LLDB, e.g:
"target modules load --file test.elf .data 0 .crom 0x4000 .text
0x8000". However the changes introduced through
https://reviews.llvm.org/D55998 removed support for overlapping
sections, with a remark "I don't anticipate running into this
situation in the real world. However, if we do run into it, and the
current behavior is not suitable for some reason, we can implement
this logic differently."

Our immediate coping strategy was implementing the remapping in the
file parsing of ObjectFileELF, but this LLDB change makes us
apprehensive that we may start encountering similar issues elsewhere
in the LLVM tooling. Are ELF sections with overlapping addresses so
rare (or even actually invalid) that ongoing support will be fragile?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev



Hi Thomas,

I can't say what's the situation in the rest of llvm, but right now 
lldb has zero test coverage for the flow you are using, so the fact 
that this has worked until now was pretty much an accident.


The reason I chose to disallow the overlapping sections in the patch 
you quote was because it was very hard to say what will be the meaning 
of this to the upper layers of lldb. For instance, a lot things in 
lldb work with "file addresses" (that is, virtual address, as they are 
known in the file, without any remapping). This means that the 
overlapping sections become ambiguous even though you have remapped 
them to non-overlapping "load addresses" with the "target modules 
load" command. For instance, the result of a query like 
"SectionList::FindSectionContainingFileAddress(lldb::addr_t)" would 
depend on how exactly was the search algorithm implemented.


I believe that a long term solution here would be to introduce some 
concept of address spaces to lldb. Then these queries would no longer 
be ambiguous as the function FindSectionContainingFileAddress would 
(presumably) take an additional address-space identifier as an 
argument. I know this is what some downstream users are doing to make 
things like this work. However, this is a fairly invasive change, so 
doing something like this upstream would require a lot of previous 
discussion.


In the mean time, I believe you can just patch out the part which 
drops the overlapping sections from the section list and get behavior 
which was more-or-less identical to the old one. However, I can't 
guarantee that nothing else will break in this scenario. I also 
wouldn't be opposed to making some change to this logic upstream too, 
if we can come up with some consistent story as to what exactly this 
means.


regards,
pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


--
Zdenek Prikryl
CTO
T +420 541 141 475
Codasip.com

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Accessing physical memory while remote debugging

[Zdenek Prikryl via lldb-dev]

Hi Daniel, Sanimir,

This feature request is repeating every now and then :-). I think it's 
very useful, but it's not that easy to implement.


Additional comments embedded.

--
Zdenek Prikryl

On 11/28/2018 07:01 PM, Sanimir Agovic via lldb-dev wrote:

Hi Daniel,


On Sat, Nov 24, 2018 at 9:34 PM Daniel Shaulov via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:
> The one thing that is really missing is the ability to read/write to 
physical memory addresses.
This would indeed be a neat addition to improve debugging bare-metal 
targets, be it simulator or jtag based e.g. openocd.
My suggestion is to generalize your idea. Add support/api to access 
memory in arbitrary address spaces. Accessing physical memory would be 
just a user of this api. This way lldb could support llvm 
architectures with multiple address spaces e.g. nvidia cuda and some 
opencl implementations.



> I looked a bit at the gdb protocol and it only supports 'm' and 'M' 
for reading and writing to virtual memory, and nothing for physical 
memory.

>
> So I suggest we add a new extensions to the gdb protocol:
> QReadPhysicalMemory - works just like 'm', but with physical memory.
> QWritePhysicalMemory - works just like 'M', but with physical memory.
Have a look at the qXfer rsp packets[1] which is used for transferring 
target objects, a prototype might look like this 
qXfer:memory:read:annex:tid:offset,length (write is analogue) where 
annex denotes to an address space identifier, offset and length are 
obvious.
Similar to the x/X packet the payload is binary encoded and not hex as 
in m/M making this new packet a superset of both x and m. I also 
highly recommend to propagate memory access errors back to the 
debugger there are plenty of reasons why memory access may fail on an 
on-chip-debugger. Afaik gdb/rsp supports error messages with the 
E.errtext notation where errtext is the error message.


Seems fine.



Coming back to tid, it is the thread id. Rsp is a stateful protocol 
and for certain operations it needs to switch the thread. This avoids 
switching back and forth and is similar to the lldb extension 
QThreadSuffixSupported[2].
Passing a tid is not needed to read memory from a process and it seems 
rather unusual but for a jtag debugger it is required to correctly 
translate the virtual address if a mmu is enabled. It is up to the 
target how to interpret tid.



> I am willing to work on adding support for this in lldb and in qemu. 
In fact, the qemu part was so easy and straightforward, that I already 
have a branch ready with the change.
Provide an API similar to llvm to support address spaces. A prototype 
might look like this: size_t ReadMemory(addr_t addr, void *buf, size_t 
size, unsigned addr_space, lldb::SBError )
The current ReadMemory would call this new API with addr_space = 0, 
the default address space.


The last time we discussed this issue we ended with an additional type 
for the address with an address space id (e.g., class AddressBase). The 
reason for it is that you need to propagate the address space id to 
expression evaluation and other parts as well. So, the relation would be 
lldb::addr_t < AddressBase < Address.


The big challenge here is to patch all lldb::addr_t instances that 
represent memory addresses to AddressBase (lldb::addr_t is used for 
non-address data time to time as well). Who's volunteering for it? :-)...





> The lldb part is a bit more tricky. At the core, changing 
ProcessGDBRemote.cpp:2776, writing  "QReadPhysicalMemory" instead of 
'm', is enough to change ALL the reads to physical memory. But we 
don't want that. So we need to add a new flag to 
CommandObjectMemoryRead, and pass it in CommandObjectMemory.cpp:669, 
then pass the flag to Process::ReadMemory. Here it gets a bit tricky, 
since Process::ReadMemory has a cache, so we can't just pass the flag 
to ReadMemoryFromInferior, we need to have a separate cache for it.

You need a per addresspace cache.


Correct, caches has to be address space aware (I think there are several 
of them).





> 3. I know it's the wrong place to ask, but does anyone know how 
accepting the qemu community will be with the patch? Have they ever 
accepted patches aimed at making lldb work better with the gdbstub, or 
is it strictly for debugging with gdb proper?
There is no right way but providing tests with your patches, keeping 
them small and rather independent of each other, and adding 
documentation is a good start.


To fully support address spaces one needs to interpret the debug 
information correctly to dispatch the memory access to the right 
address space and the type system needs to be extended as well. Having 
a way to query for available address spaces would also be helpful. 
Keep in mind to extend the lldb commands to expose this feature to the 
user

memory read/write --asid  | --asid-name 
memory list
disassemble --asid  | --asid-name 


That is correct as well.



[1] 

Re: [lldb-dev] Advice on architectures with multiple address spaces

[Zdenek Prikryl via lldb-dev]

Just a small update. I did create the class AddressBase. Class Address 
inherits from it. When I compare it with my first implementation, it's 
cleaner than the additional argument in API. I also implemented all 
operators to the class AddressBase, so it behaves like addr_t if you're 
not interested in the address space.


I thought that I'd rename the class AddressBase to addr_t and see what 
would happen, but then I realized that LLDB has python support and I'm 
not sure how this works with classes, so, any advice here?


Btw. I still don't have a clear answer to my question below...

Zdenek

On 05/17/2018 03:45 PM, Zdenek Prikryl wrote:

Greg, Jim, what's your opinion here?

What about having the class Address (pretty much as it is right now) 
and the


struct AddressBase {
  lldb::addr_t m_address;
  lldb::as_t m_address_space;
  ...
}

Another question is, which classes/code should use Address, 
AddressBase, and addr_t. Do you have any idea here?


Zdenek

On 05/17/2018 01:38 PM, Pavel Labath wrote:

The Address class may be suitable for the higher layers of lldb, but I
don't think the it can ever be a blanket replacement for 
lldb::addr_t. It
has way too much smartness built-in. We use addr_t in a lot of places 
that
don't/shouldn't care about Targets, ExecutionContexts or Sections. 
All of
lldb-server is one of those places, but this is also true for any 
low-level

operation which only wants to work with real (virtual) addresses in the
process address space.

On the other hand, replacing addr_t with a lighweight struct which is 
just

adds some sort of an address space identifier seems like a useful thing,
and would go a long way towards bringing Harward architecture support to
lldb-server. (Note that we would still need an addr_t or something of 
that

form to name the type of the "address" member of the struct, but pretty
much all of the apis that currently take addr_t, could that the new 
struct

instead).


On Thu, 17 May 2018 at 12:01, Zdenek Prikryl via lldb-dev <
lldb-dev@lists.llvm.org> wrote:



On 04/19/2018 08:22 PM, Jim Ingham wrote:
On Apr 19, 2018, at 10:54 AM, Greg Clayton <clayb...@gmail.com> 
wrote:





On Apr 19, 2018, at 10:35 AM, Jim Ingham <jing...@apple.com> wrote:




On Apr 19, 2018, at 9:44 AM, Greg Clayton via lldb-dev <

lldb-dev@lists.llvm.org> wrote:




On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev <

lldb-dev@lists.llvm.org> wrote:

Hi lldb developers,

I've been researching using lldb + gdbserver stub that is based on

Harvard architecture with multiple address spaces (one program, multiple
data). The commonly adopted approach is that everything is mapped to a
single "virtual" address space. The stub reads/writes from/to the right
memory based on the "virtual" addresses. But I'd like to use real 
addresses
with address space id instead. So, I've started looking at what has 
to be

changed.

I've enhanced read/write commands (e.g. memory read --as  ...)

and RSP protocol (new packet) so that the stub can read/write properly.
That wasn't that complicated.

It might be nice to add a new RSP protocol packet that asks for the

address space names/values:

qGetAddressSpaces

which would return something like:

1:text;2:data1,3:data2

or it would return not supported. If we get a valid return value
from qGetAddressSpaces, then it enables the use of the new packet you 
added

above. Else it defaults to using the old memory read functions.


Now I've hit an issue with expressions (LLVMUserExpression.cpp) 
and
local variables (DWARFExpressions.cpp). There is a lot of memory 
read/write

functions that take just an address argument. Is the only way to go to
patch all these calls? Has anybody solved it differently?

My quick take is that any APIs that take just a lldb::addr_t would

need to take something like:

struct SpaceAddress {
static constexpr uint32_t kNoSpace = 0;
lldb::addr_t addr;
uint32_t space;
};


I'm curious why you are suggesting another kind of address, rather
than adding this functionality to Address?  When you actually go to 
resolve
an Address in a target with a process you should have everything you 
need
to know to give it the proper space.  Then fixing the expression 
evaluator

(and anything else that needs fixing) would be a matter of consistently
using Address rather than lldb::addr_t.  That seems general goodness, 
since

converting to an lldb::addr_t loses information.

If we accept lldb_private::Address in all APIs that take a
lldb::addr_t currently, then we need to always be able to get to the 
target

in case we need to add code to resolve the address everywhere. I am
thinking of SpaceAddress as an augmented lldb::addr_t instead of a 
section
+ offset style address. Also, there will be addresses in the code and 
data

that do not exist in actual sections. Not saying that you couldn't use
lldb_private::Address. I am open to suggestions though. So your 
though it

remove 

Re: [lldb-dev] Advice on architectures with multiple address spaces

[Zdenek Prikryl via lldb-dev]

Greg, Jim, what's your opinion here?

What about having the class Address (pretty much as it is right now) and 
the


struct AddressBase {
  lldb::addr_t m_address;
  lldb::as_t m_address_space;
  ...
}

Another question is, which classes/code should use Address, AddressBase, 
and addr_t. Do you have any idea here?


Zdenek

On 05/17/2018 01:38 PM, Pavel Labath wrote:

The Address class may be suitable for the higher layers of lldb, but I
don't think the it can ever be a blanket replacement for lldb::addr_t. It
has way too much smartness built-in. We use addr_t in a lot of places that
don't/shouldn't care about Targets, ExecutionContexts or Sections. All of
lldb-server is one of those places, but this is also true for any low-level
operation which only wants to work with real (virtual) addresses in the
process address space.

On the other hand, replacing addr_t with a lighweight struct which is just
adds some sort of an address space identifier seems like a useful thing,
and would go a long way towards bringing Harward architecture support to
lldb-server. (Note that we would still need an addr_t or something of that
form to name the type of the "address" member of the struct, but pretty
much all of the apis that currently take addr_t, could that the new struct
instead).


On Thu, 17 May 2018 at 12:01, Zdenek Prikryl via lldb-dev <
lldb-dev@lists.llvm.org> wrote:



On 04/19/2018 08:22 PM, Jim Ingham wrote:

On Apr 19, 2018, at 10:54 AM, Greg Clayton <clayb...@gmail.com> wrote:




On Apr 19, 2018, at 10:35 AM, Jim Ingham <jing...@apple.com> wrote:




On Apr 19, 2018, at 9:44 AM, Greg Clayton via lldb-dev <

lldb-dev@lists.llvm.org> wrote:




On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev <

lldb-dev@lists.llvm.org> wrote:

Hi lldb developers,

I've been researching using lldb + gdbserver stub that is based on

Harvard architecture with multiple address spaces (one program, multiple
data). The commonly adopted approach is that everything is mapped to a
single "virtual" address space. The stub reads/writes from/to the right
memory based on the "virtual" addresses. But I'd like to use real addresses
with address space id instead. So, I've started looking at what has to be
changed.

I've enhanced read/write commands (e.g. memory read --as  ...)

and RSP protocol (new packet) so that the stub can read/write properly.
That wasn't that complicated.

It might be nice to add a new RSP protocol packet that asks for the

address space names/values:

qGetAddressSpaces

which would return something like:

1:text;2:data1,3:data2

or it would return not supported. If we get a valid return value

from qGetAddressSpaces, then it enables the use of the new packet you added
above. Else it defaults to using the old memory read functions.



Now I've hit an issue with expressions (LLVMUserExpression.cpp) and

local variables (DWARFExpressions.cpp). There is a lot of memory read/write
functions that take just an address argument. Is the only way to go to
patch all these calls? Has anybody solved it differently?

My quick take is that any APIs that take just a lldb::addr_t would

need to take something like:

struct SpaceAddress {
static constexpr uint32_t kNoSpace = 0;
lldb::addr_t addr;
uint32_t space;
};


I'm curious why you are suggesting another kind of address, rather

than adding this functionality to Address?  When you actually go to resolve
an Address in a target with a process you should have everything you need
to know to give it the proper space.  Then fixing the expression evaluator
(and anything else that needs fixing) would be a matter of consistently
using Address rather than lldb::addr_t.  That seems general goodness, since
converting to an lldb::addr_t loses information.

If we accept lldb_private::Address in all APIs that take a

lldb::addr_t currently, then we need to always be able to get to the target
in case we need to add code to resolve the address everywhere. I am
thinking of SpaceAddress as an augmented lldb::addr_t instead of a section
+ offset style address. Also, there will be addresses in the code and data
that do not exist in actual sections. Not saying that you couldn't use
lldb_private::Address. I am open to suggestions though. So your though it
remove all API that take lldb::addr_t and use lldb_private::Address
everywhere all the time?

It has always bugged me that we have these two ways of specifying

addresses.  Are there many/any places that have to resolve an Address to a
real address in a process that don't have a Target readily available?  That
would surprise me.  I would much rather centralize on one way than adding a
third.

Jim

So, does it make sense to start with lldb::addr_t replacement? In other
words, replace all instances of lldb::addr_t with Address. It'd be the
first step and first patch towards to the ability to extend it in the
future, right?
Zdenek





Jim



We would need a default value for "

Re: [lldb-dev] Advice on architectures with multiple address spaces

[Zdenek Prikryl via lldb-dev]

On 04/19/2018 08:22 PM, Jim Ingham wrote:



On Apr 19, 2018, at 10:54 AM, Greg Clayton <clayb...@gmail.com> wrote:




On Apr 19, 2018, at 10:35 AM, Jim Ingham <jing...@apple.com> wrote:




On Apr 19, 2018, at 9:44 AM, Greg Clayton via lldb-dev 
<lldb-dev@lists.llvm.org> wrote:




On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev 
<lldb-dev@lists.llvm.org> wrote:

Hi lldb developers,

I've been researching using lldb + gdbserver stub that is based on Harvard architecture with 
multiple address spaces (one program, multiple data). The commonly adopted approach is that 
everything is mapped to a single "virtual" address space. The stub reads/writes from/to 
the right memory based on the "virtual" addresses. But I'd like to use real addresses 
with address space id instead. So, I've started looking at what has to be changed.

I've enhanced read/write commands (e.g. memory read --as  ...) and RSP 
protocol (new packet) so that the stub can read/write properly. That wasn't that 
complicated.

It might be nice to add a new RSP protocol packet that asks for the address 
space names/values:

qGetAddressSpaces

which would return something like:

1:text;2:data1,3:data2

or it would return not supported. If we get a valid return value from 
qGetAddressSpaces, then it enables the use of the new packet you added above. 
Else it defaults to using the old memory read functions.



Now I've hit an issue with expressions (LLVMUserExpression.cpp) and local 
variables (DWARFExpressions.cpp). There is a lot of memory read/write functions 
that take just an address argument. Is the only way to go to patch all these 
calls? Has anybody solved it differently?

My quick take is that any APIs that take just a lldb::addr_t would need to take 
something like:

struct SpaceAddress {
static constexpr uint32_t kNoSpace = 0;
lldb::addr_t addr;
uint32_t space;
};


I'm curious why you are suggesting another kind of address, rather than adding 
this functionality to Address?  When you actually go to resolve an Address in a 
target with a process you should have everything you need to know to give it 
the proper space.  Then fixing the expression evaluator (and anything else that 
needs fixing) would be a matter of consistently using Address rather than 
lldb::addr_t.  That seems general goodness, since converting to an lldb::addr_t 
loses information.

If we accept lldb_private::Address in all APIs that take a lldb::addr_t 
currently, then we need to always be able to get to the target in case we need 
to add code to resolve the address everywhere. I am thinking of SpaceAddress as 
an augmented lldb::addr_t instead of a section + offset style address. Also, 
there will be addresses in the code and data that do not exist in actual 
sections. Not saying that you couldn't use lldb_private::Address. I am open to 
suggestions though. So your though it remove all API that take lldb::addr_t and 
use lldb_private::Address everywhere all the time?

It has always bugged me that we have these two ways of specifying addresses.  
Are there many/any places that have to resolve an Address to a real address in 
a process that don't have a Target readily available?  That would surprise me.  
I would much rather centralize on one way than adding a third.

Jim


So, does it make sense to start with lldb::addr_t replacement? In other 
words, replace all instances of lldb::addr_t with Address. It'd be the 
first step and first patch towards to the ability to extend it in the 
future, right?


Zdenek






Jim



We would need a default value for "space" (feel free to rename) that indicates 
the default address space as most of our architectures would not need this support. If we 
added a constructor like:

SpaceAddress(lldb::addr_t a) : addr(a), space(kNoSpace) {}

Then all usages of the APIs that used to take just a "lldb::addr_t" would 
implicitly call this constructor and continue to act as needed. Then we would need to 
allow lldb_private::Address objects to resolve to a SpaceAddress:

SpaceAddress lldb_private::Address::GetSpaceAddress(Target *target) const;

Since each lldb_private::Address has a section and each section knows its 
address space. Then the tricky part is finding all locations in the expression 
parser and converting those to track and use SpaceAddress. We would probably 
need to modify the allocate memory packets in the RSP protocol to be able to 
allocate memory in any address space as well.

I didn't spend much time think about correct names above, so feel free to 
suggest alternate naming.

Best advice:
- make things "just work" to keep changes to a minimum and allowing 
lldb::addr_t to implicitly convert to a SpaceAddress easily
- when modifying RSP, make sure to check for existence of new feature before 
enabling it
- query for address space names so when we dump SpaceAddress we can show 
something that means something to the user. This means we 

[lldb-dev] Registers in expressions on big endian target

[Zdenek Prikryl via lldb-dev]

Hi,

Is anybody familiar with (De)materializer in the expressions for 
registers? I'm facing really weird behavior. I have big endian target 
and if I do register read, I got the correct results (e.g. 0x11223344), 
but if I do print , I got 0x44332211. It seems that the 
EntityRegister swap bytes when Materialize() is handled, but it's not 
swapped again during Dematerialize(). It's really unfortunate, because I 
cannot use registers in expressions for breakpoints etc. (the result is 
always wrong).


Note that little endian targets are fine.

Any thoughts how it should be properly fixed?

--
Zdenek Prikryl

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Advice on architectures with multiple address spaces

[Zdenek Prikryl via lldb-dev]

Maybe Kalimba developers can help here. Kalimba has crazy memory map...:-)

--
Zdenek

On 04/19/2018 08:32 PM, Ted Woodward wrote:

Hexagon has a single address space, so we don't need to do anything like this.

When I worked on Motorola 56xxx DSPs we had memory spaces, but we didn't use 
RSP. We had our own protocol that used a struct for addreses, with the space 
(an enum, defined per supported core) and a uint32_t (later 2 of them) for the 
address.

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg
Clayton via lldb-dev
Sent: Thursday, April 19, 2018 11:45 AM
To: Zdenek Prikryl 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Advice on architectures with multiple address spaces

You might ask

the Hexagon folks if they have done anything in case they already support this
is some shape or form.

Greg Clayton






___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Advice on architectures with multiple address spaces

[Zdenek Prikryl via lldb-dev]

On 04/19/2018 08:22 PM, Jim Ingham wrote:

On Apr 19, 2018, at 10:54 AM, Greg Clayton <clayb...@gmail.com> wrote:




On Apr 19, 2018, at 10:35 AM, Jim Ingham <jing...@apple.com> wrote:




On Apr 19, 2018, at 9:44 AM, Greg Clayton via lldb-dev 
<lldb-dev@lists.llvm.org> wrote:




On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev 
<lldb-dev@lists.llvm.org> wrote:

Hi lldb developers,

I've been researching using lldb + gdbserver stub that is based on Harvard architecture with 
multiple address spaces (one program, multiple data). The commonly adopted approach is that 
everything is mapped to a single "virtual" address space. The stub reads/writes from/to 
the right memory based on the "virtual" addresses. But I'd like to use real addresses 
with address space id instead. So, I've started looking at what has to be changed.

I've enhanced read/write commands (e.g. memory read --as  ...) and RSP 
protocol (new packet) so that the stub can read/write properly. That wasn't that 
complicated.

It might be nice to add a new RSP protocol packet that asks for the address 
space names/values:

qGetAddressSpaces

which would return something like:

1:text;2:data1,3:data2

or it would return not supported. If we get a valid return value from 
qGetAddressSpaces, then it enables the use of the new packet you added above. 
Else it defaults to using the old memory read functions.


Sounds good to me. I would return more information though. For instance, 
you can have a code address space where a 32bit byte is used and data 
address space where an 8bit byte is used. Some support for this is 
already in LLDB, although it's not tied to address spaces, but to an 
architecture.






Now I've hit an issue with expressions (LLVMUserExpression.cpp) and local 
variables (DWARFExpressions.cpp). There is a lot of memory read/write functions 
that take just an address argument. Is the only way to go to patch all these 
calls? Has anybody solved it differently?

My quick take is that any APIs that take just a lldb::addr_t would need to take 
something like:

struct SpaceAddress {
static constexpr uint32_t kNoSpace = 0;
lldb::addr_t addr;
uint32_t space;
};


I'm curious why you are suggesting another kind of address, rather than adding 
this functionality to Address?  When you actually go to resolve an Address in a 
target with a process you should have everything you need to know to give it 
the proper space.  Then fixing the expression evaluator (and anything else that 
needs fixing) would be a matter of consistently using Address rather than 
lldb::addr_t.  That seems general goodness, since converting to an lldb::addr_t 
loses information.

If we accept lldb_private::Address in all APIs that take a lldb::addr_t 
currently, then we need to always be able to get to the target in case we need 
to add code to resolve the address everywhere. I am thinking of SpaceAddress as 
an augmented lldb::addr_t instead of a section + offset style address. Also, 
there will be addresses in the code and data that do not exist in actual 
sections. Not saying that you couldn't use lldb_private::Address. I am open to 
suggestions though. So your though it remove all API that take lldb::addr_t and 
use lldb_private::Address everywhere all the time?

It has always bugged me that we have these two ways of specifying addresses.  
Are there many/any places that have to resolve an Address to a real address in 
a process that don't have a Target readily available?  That would surprise me.  
I would much rather centralize on one way than adding a third.

Jim


I'd like to remove more ways of describing the same thing, so going with 
the Address() sounds better. Having said that, there are about 4k 
instances of lldb::addr_t in LLDB code base. Where to begin/how to split 
the work? :-)...






Jim



We would need a default value for "space" (feel free to rename) that indicates 
the default address space as most of our architectures would not need this support. If we 
added a constructor like:

SpaceAddress(lldb::addr_t a) : addr(a), space(kNoSpace) {}

Then all usages of the APIs that used to take just a "lldb::addr_t" would 
implicitly call this constructor and continue to act as needed. Then we would need to 
allow lldb_private::Address objects to resolve to a SpaceAddress:

SpaceAddress lldb_private::Address::GetSpaceAddress(Target *target) const;

Since each lldb_private::Address has a section and each section knows its 
address space. Then the tricky part is finding all locations in the expression 
parser and converting those to track and use SpaceAddress. We would probably 
need to modify the allocate memory packets in the RSP protocol to be able to 
allocate memory in any address space as well.

I didn't spend much time think about correct names above, so feel free to 
suggest alternate naming.

Best advice:
- make things "just work" to keep changes to a minimum

[lldb-dev] Advice on architectures with multiple address spaces

[Zdenek Prikryl via lldb-dev]

Hi lldb developers,

I've been researching using lldb + gdbserver stub that is based on 
Harvard architecture with multiple address spaces (one program, multiple 
data). The commonly adopted approach is that everything is mapped to a 
single "virtual" address space. The stub reads/writes from/to the right 
memory based on the "virtual" addresses. But I'd like to use real 
addresses with address space id instead. So, I've started looking at 
what has to be changed.


I've enhanced read/write commands (e.g. memory read --as  ...) and 
RSP protocol (new packet) so that the stub can read/write properly. That 
wasn't that complicated.


Now I've hit an issue with expressions (LLVMUserExpression.cpp) and 
local variables (DWARFExpressions.cpp). There is a lot of memory 
read/write functions that take just an address argument. Is the only way 
to go to patch all these calls? Has anybody solved it differently?


Thanks for any advice.

--
Zdenek

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev