Otherwise the permutations are endless
From: Ted Woodward
Sent: Friday, May 25, 2018 9:44:53 AM
To: Duane Ellis; 'Zdenek Prikryl'; lldb-dev@lists.llvm.org
Subject: RE: [lldb-dev] Advice on architectures with multiple address spaces
You can conceptually take th
oject
> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Duane
> Ellis via lldb-dev
> Sent: Friday, May 25, 2018 9:40 AM
> To: Zdenek Prikryl
> Cc: LLDB
> Subject: Re: [lldb-dev] Advice on architectures with multiple address spaces
>
As an FYI - this is another way of looking at Address spaces.. I like the word
“Route” to the memory space, i think it defines the problem better.
All Armv8 chips effectively have - multiple address available to the debugger
For instance, a JTAG debugger halts an ARMV8 cpu core, and the core hal
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 intereste
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 h
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-
On 04/19/2018 08:22 PM, Jim Ingham wrote:
On Apr 19, 2018, at 10:54 AM, Greg Clayton wrote:
On Apr 19, 2018, at 10:35 AM, Jim Ingham wrote:
On Apr 19, 2018, at 9:44 AM, Greg Clayton via lldb-dev
wrote:
On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev
wrote:
Hi lldb d
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 multip
On 04/19/2018 08:22 PM, Jim Ingham wrote:
On Apr 19, 2018, at 10:54 AM, Greg Clayton wrote:
On Apr 19, 2018, at 10:35 AM, Jim Ingham wrote:
On Apr 19, 2018, at 9:44 AM, Greg Clayton via lldb-dev
wrote:
On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev
wrote:
Hi lldb dev
f 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 alrea
> On Apr 19, 2018, at 10:54 AM, Greg Clayton wrote:
>
>
>
>> On Apr 19, 2018, at 10:35 AM, Jim Ingham wrote:
>>
>>
>>
>>> On Apr 19, 2018, at 9:44 AM, Greg Clayton via lldb-dev
>>> wrote:
>>>
>>>
>>>
On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev
wrote:
>>
> On Apr 19, 2018, at 10:35 AM, Jim Ingham wrote:
>
>
>
>> On Apr 19, 2018, at 9:44 AM, Greg Clayton via lldb-dev
>> wrote:
>>
>>
>>
>>> On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev
>>> wrote:
>>>
>>> Hi lldb developers,
>>>
>>> I've been researching using lldb + gdbserve
> On Apr 19, 2018, at 9:44 AM, Greg Clayton via lldb-dev
> wrote:
>
>
>
>> On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev
>> wrote:
>>
>> Hi lldb developers,
>>
>> I've been researching using lldb + gdbserver stub that is based on Harvard
>> architecture with multiple address
> On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev
> 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 everyt
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 t
15 matches
Mail list logo
