From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43962 invoked by alias); 13 Jan 2016 18:06:33 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 43949 invoked by uid 89); 13 Jan 2016 18:06:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.8 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=Class, Virtual, semi, modifiers X-HELO: p3plwbeout03-03.prod.phx3.secureserver.net Received: from p3plsmtp03-03-2.prod.phx3.secureserver.net (HELO p3plwbeout03-03.prod.phx3.secureserver.net) (72.167.218.215) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 13 Jan 2016 18:06:31 +0000 Received: from localhost ([72.167.218.131]) by p3plwbeout03-03.prod.phx3.secureserver.net with bizsmtp id 5W6V1s0012qhQio01W6VBT; Wed, 13 Jan 2016 11:06:29 -0700 X-SID: 5W6V1s0012qhQio01 Received: (qmail 15044 invoked by uid 99); 13 Jan 2016 18:06:29 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" User-Agent: Workspace Webmail 5.16.0 Message-Id: <20160113110628.5c1bb9f86d671edec44bb378f25c04cc.e9d65e199e.wbe@email03.secureserver.net> From: To: "Luis Machado" , "James Bowman" , "gdb@sourceware.org" Subject: RE: Harvard architecture and gdb Date: Wed, 13 Jan 2016 18:06:00 -0000 Mime-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00012.txt.bz2 > FT32 has two address spaces, flash and RAM. They both occupy addresses st= arting 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. Hmm - interesting problem, there are other examples of this when you are working in the bare metal world ( a place that GDB does not work very well ) =3D=3D=3D=3D This subject came upon the OpenOCD mailing list {OpenOCD =3D Open source JTAG debugger} here: (see item #2 and #3 in that email) http://sourceforge.net/p/openocd/mailman/openocd-devel/thread/2015042823455= 7.8376.qmail@stuge.se/ =3D=3D=3D=3D for example - Debugging the Linux kernel, you have:=20=20 (A) Physical vrs Virtual. (B) User vrs Kernel (C) Secure vrs Non-Secure [ie: Think ARM TrustZone] (D) Hypervisor vrs non-Hypervisor space If you are dealing with an SOC - such as an ARM based one with a DAP, there are also multiple address spaces (one for each memory-type DAP interface) There are also systems that allow you to access target memory *WHILE* the CPU is running, without halting the CPU - this is a wonderful tool for debugging! ARM also has the COPROCESSOR interfaces, which is sort of a memory interface. Other debuggers, specifically Lauterbach have a prefix that acts as an attribute. that you can place on the front of an address, in fact you can also define a SYMBOL that contains both an address *AND* an attribute. Lauterbach's terms are: "Access Class" - an example can be found here: http://www2.lauterbach.com/pdf/debugger_arm.pdf Specifically page 37, Table: "Access Class" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D here's the solution that I think would solve it, but it means some *MASSIVE* changes internal to GDB, and the GDB protocol What would be very helpful is this: Define a Memory address as the combination of=20 (A) a Nbit number - this needs to be at least 64bit for all targets, even if the debug target is 32bit=20 Example: An SOC with a 64bit cpu and a 32bit power management cpu (B) A route ID {see below} (C) Route specific flags There is always 'a default route' ie: RouteID =3D 0 means do this the normal way, via the CPU, in the current mode... etc. =3D=3D=3D=3D there are actually 2 structures needed: (1) A memory attribute structure And a means to create arbitrary target specific attributes. (2) a memory address structure. Today GDB passes a address around as a "generic 64bit number" - that needs to change to become a small structure, the "memory address" structure. In my mind the structs would look like this: struct mem_address { /* RouteID=20 * 0 =3D default, normal what ever that might be. * then a list of well known semi standardized names * 1 =3D Virtual * 2 =3D Physical * 3 =3D Kernel * 4 =3D IO space * 5 =3D Code * 6 =3D Data * ... perhaps other standard names ... * * 100 ... 200 =3D Technology specific=20 * 200 ... 300 =3D another technology=20 * ie: ARM or MIPs, or AVR specific. * * 1000 - a range for hardware specific. */ int route_id;=20=20=20 /* Modifiers for the route * bits[0:15] =3D might be standard flags. * bits[16:32] =3D defined by the specific route * * Example: bit 0 =3D virtual vrs phys * bit 1 =3D clean the cache after the operation * bit [3:2] =3D user, kernel, Hypervisor, spare */ uint64_t route_flags; // Of course the address. uint64_t address; }; And the separately a memory attribute, defined like this: struct mem_attr { const char *name; // used to initialize a mem_address:route_id uintt4_t route_id; // used to initialize a mem_addresss:route_flags uint64_t route_flags; }; The user should be able to specify, like the Lauterbach solution: dump memory at: SA:0x1234 [ meaning: kernel mode, absolute address ] Or create their own =20 create attribute: name =3D foo, route =3D 0x1234, attribute =3D 0x3234 Then use the attribute like this: dump memory at: foo:0x1234 The existing code that parses an address would change - instead of returning an address (64bit number) would need use a structure. That code would: Recognize the list of prefix names (see: mem_attr:name) And initialize a "mem_address" route_id and route_attribute based on the named attribute. If no prefix is found, then the "route_id =3D 0, and route_flags =3D 0 [which is the default] =3D=3D=3D=3D=3D This sort of stuff needs to be transmitted "over the wire[socket]" to the target control device [ie: The JTAG-GDB-SERVER] so that it can access memory correctly. Oh my this is super invasive. -Duane.