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 halts in
user space - the question is what are the various address spaces a developer
might want to dump memory for:
A) The current user space view of memory - to print a user space variable.
B) The current Kernel (OS) view of memory - perhaps to print data structure in
kernel space
C) At the hypervisor level which is the core’s view of physical memory -
perhaps the developer wants to examine a data structure or variable in the
hypervisor.
D) The ARM dap - has 3 (sometime 4) memory bus interfaces. They are typically:
Dap Port 0 - is typically the main system bus, often the same as the CPU’s
connection to the main system bus but not exactly
ie: CPU access to a multi-media bus, via a dedicated connection/address range,
in contrast the main system bus has a different connection/route to the
multimedia memory
Dap Port 1 - commonly provides access to various Coresight items for most of
the cores.
Dap Port 2 - Varies - it could be an embedded Jtag controller - say with an
ARM9 or other JTAG only interface)
Dap Port 3 - Varies - But often there are a few CORTEX M series CPUs - and I
believe each M3 on the target must have its own dedicated DAP interface.
Assume for a moment, each of these address spaces have a name, there is the
default, then there needs to be various override methods
Being able to some how specify these different “access routes” is helpful when
debugging hardware at the bare metal level.
In the above, I’m not talking about looking at a complex variable (that would
be really nice, ie: cast a memory address to a fancy type)
When debugging a SYSTEM - this becomes very important. Minimally being able to
have a “memory window” that can specify the route is helpful - for example
Dump Memory at : HyperVisor address 0x12345678
Dump Memory at: Kernel address 0x45678901234
Dump Memory using the system bus interface
Across multiple cores - you have
1) Some very common routes - ie: “In the current context” vrs “Kernel context”
These should have commonly defined names.
2) Some platforms may need to add their own “platform defined” items (ie:
various armv8 routes would be semi-common)
3) Some VERY specific routes or methods that are developer defined - For
example when accessing memory via the DAP MEM_AP, there are special bits in the
control register (controlling security and/or cache control). Maybe the
developer needs to set those a special way when performing the memory access
when using this “route”
The lauterbach jtag debugger can do the above now (it is an address prefix)
The ARM debugger (If I remember correctly) can also do this somewhere in its
script language.
But tools like GDB and LLDB can not
Because tools like GDB and LLDB have a scripting language (ie: Python) - being
able to write a script in that scripting language and be able to specify the
ROUTE is important.
For example, a script that writes to a bunch of hardware locations via the
MEMAP (or possibly via different CPU) - to enable a feature so that you can run
test/validation code
Examples include write to a hardware register to turn a CLOCK on, or
disable/enable a security protection bit so that you can view/write to the
memory location.
-Duane.
> On May 25, 2018, at 5:35 AM, Zdenek Prikryl via lldb-dev
> wrote:
>
> 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, Executio
Re: [lldb-dev] Advice on architectures with multiple address spaces
>> cache view Debugging cache problems is always fun, being able to do this is very helpful. >> You can conceptually take this a step further. This is exactly my point, these would be in a “target specific” range of prefix names When specifying an address, there should be some set of “common names” that all CPUs use For example: default:0x12345, phys:0x12345, or user:0x12345, kern:0x12345, hype:0x12345 - for default (ie: current cpu mode/configuration, used when route is not specified) and memory spaces like physical, user, kernel, hypervisor In Ted’s example case Ie: DSCR:0x12345 -> Translates to DSCR at address 0x12345 Where as ARM cores might have their own set of special names Field the route value needs two field– Major = (at least 16bits, ie: cpu core) and Minor (16bits) core specific. Also need to reserve a range for “non-core” like accesses known only by the debug agent/server/hardware interface, the user might want to say: Name: “FOO” means - access_route(X), with configuration value: (some 32bit integer) that is unknown at the debugger level, but know/understood at the lower level. 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 this a step further. I used to work at Freescale, and supported SoCs with multiple heterogeneous cores. I provided memory spaces that let the user access these memory views: - DCSR (debug memory, a separate bus) through the SoC - CCSR (memory mapped config registers) through the SoC - cache coherent physical access through the SoC - uncached physical access through the SoC - virtual access through a given core (PPC or StarCore) - cache coherent physical access through a given core - uncached physical access through a given core I also provided a cache view which would allow the user to read/modify data and tag/status of the L1i, L1d, L2 and L3 caches. Basically, let the user access memory (whether it was RAM, memory mapped registers, or something else) any way he or she wants. What the core sees, what the SoC sees, cacheable, uncached (so, in the backing store), or what's in the caches. Once you have memory space support, you can make arbitrary spaces that show you whatever you want. -- 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 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 halts in > user space - the question is what are the various address spaces a developer > might want to dump memory for: > > A) The current user space view of memory - to print a user space variable. > > B) The current Kernel (OS) view of memory - perhaps to print data structure in > kernel space > > C) At the hypervisor level which is the core’s view of physical memory - > perhaps > the developer wants to examine a data structure or variable in the hypervisor. > > D) The ARM dap - has 3 (sometime 4) memory bus interfaces. They are > typically: > > Dap Port 0 - is typically the main system bus, often the same as the CPU’s > connection to the main system bus but not exactly > > ie: CPU access to a multi-media bus, via a dedicated connection/address range, > in contrast the main system bus has a different connection/route to the > multimedia memory > > Dap Port 1 - commonly provides access to various Coresight items for most of > the cores. > > Dap Port 2 - Varies - it could be an embedded Jtag controller - say with an > ARM9 or other JTAG only interface) > > Dap Port 3 - Varies - But often there are a few CORTEX M series CPUs - and I > believe each M3 on the target must have its own dedicated DAP interface. > > Assume for a moment, each of these address spaces have a name, there is the > default, then there needs to be various override methods > > Being able to some how specify these different “access routes” is helpful when > debugging hardware at the bare metal level. > > In the above, I’m not talking about looking at a complex variable (that would > be > re
Re: [lldb-dev] How does attach work on non-Windows?
> > On Aug 26, 2015, at 2:20 PM, Zachary Turner via lldb-dev > wrote: > > Slightly related, but do other platforms have a way to check from an inferior > if a debugger is present? > > We need to do this frequently from the test inferiors, and I see lots of > different approaches used in the test programs, none of which work correctly > on Windows. > This is the proper way to do this under windows: BOOL WINAPI IsDebuggerPresent(void); This related function is often helpful: void WINAPI DebugBreak(void); ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] filenames in a cross-platform environment
> On Aug 27, 2015, at 4:17 PM, via lldb-dev wrote: > > Hi all, > > The question of how to tackle filename/path issues in a cross-platform > environment arose as a result of http://reviews.llvm.org/D12115, and we would > like to continue that discussion here. I'll start with excerpts from comments > in that review to give you some background: > [snip] > > Thoughts/ideas? I solved this quite a few years ago inside of “GDB-TK/Insight” - my situation was: Some libraries are built on: Linux + SunOS + Cygwin + MSDOS + MAC (prior to Unix-fication, colons in the path) Libraries and Apps could be built on any of those. Hence we had many different combiations. Today - you are talking about LLDB - which potentially has python under the hood. In my case GDB-TK/Insight - it was Tcl/Tk built in. My solution worked like this: When GDB failed to find the filename by “the normal means” - I made GDBTK call a TCL/TK function If that function did not exist - the code just gave up - too bad you do not get to find the file. This was the default action if you (the user) did not provide a lookup function. If that function existed - in my case, we wrote one or two functions for each project And, when you launched GDB we just did a “source project_paths.tcl” in the .gdbinit script The beauty is this: You will never get all of these features and corner cases resolved. The solution is very adaptable, and the user can do what is required. The user can - if they desire - write a fix-up function The default implementation would be this simple - it does nothing. def my_find_my_file( filename ): # Default implementation .. just return the filename return filename You could, get really fancy - You could go lookup the file name via a GIT-WEB service and pull it locally. Thus you do not need 100% of the source code present it comes in on demand. But that is a *USER* solution - all you are doing is calling a function they can write. Example: def my_find_my_file(filename): if filename.startswith( ‘/proj/libfoo/rev1.0’ ): return git_web_lookup( foo_server, filename ); else: return filename NOTE: Please … I beg you: Do not pass the base-name, pass the entire path from the debug record. Why? Because often you find duplicate filenames the full path is better! Even better: Pass the symbol name, the address, and line number the function. And - the DW_LNF_MD5 (md5 sum of the source file?) And … the list goes on and on In the LLDB case, that function could be written by the user in Python or perhaps example python template can be provided with some simple instructions. -Duane. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
