[lldb-dev] Proposal: How to modify lldb for non 8-bit bytes for kalimba processors
Matthew Gardiner
mg11 at csr.com
Sun Aug 31 23:01:20 PDT 2014
Thanks for sharing your views, folks,
I'm concluding that nobody in the group is vehemently against my
proposal, so I will cautiously proceed. Regarding Todd's point, I'm
hoping to keep the presence of n-bit byte processing code down to a
minimum through out the codebase. The "layering" is certainly possible,
and I should know more about how to achieve that once I get further into
the work. One possibility would seem to involve either deriving
something from, or composing another class with, ProcessGDBRemote.
Regarding Sean's reply - we do have a full-blown simulator for all our
Kalimba architectures. For lots of reasons, though, we cannot integrate
this in the test suite. It may be possible to derive something much
simpler to fit in, though. I'll chat to some of my colleagues, to see
what can be done.
thanks
Matt
Sean Callanan wrote:
> One thing that would make testing infinitely easier is if there were a
> simulator of a 24-bit byte architecture that we could use in our test
> suite.
> It wouldn’t have to simulate the CPU or anything like that – it would
> just have to let LLDB attach (maybe via the gdb-remote protocol?) and
> vend information about a very simple core file… enough information
> that should allow LLDB to backtrace.
> Then we would just have to validate the resulting backtrace to make
> sure we haven’t regressed the fundamentals of unusual byte sizes.
>
> Sean
>
>> On Aug 29, 2014, at 9:17 AM, Todd Fiala <tfiala at google.com
>> <mailto:tfiala at google.com>> wrote:
>>
>> > "You can't possibly do that, so many other architectures have 8-bit
>> bytes, and so this proposal would make them harder to enhance, for
>> the benefit of (currently) just kalimba"
>>
>> From a design principle, I would probably vote for having
>> non-8-bit-bytes added as a layer on top of memory accesses that is
>> only used for systems that need it. I'd strongly prefer not to have
>> the generality of n-bit (or multiple of 8-bit bytes) permute
>> throughout the lldb code base. I can see that becoming challenging
>> from a maintainability standpoint (testing, code complexity, etc.)
>>
>> I could imagine a layer you build on top of memory accesses that
>> knows how to run out and grab the right underlying cpu_arch-specific
>> bytes to satisfy the request. And only wiring that in to low level
>> memory access maybe in the memory read/write virtual methods (like
>> Process::DoReadMemory() and friends).
>>
>> That's just my take. Maintainability and testability being the key
>> driver here.
>>
>>
>> On Fri, Aug 29, 2014 at 5:11 AM, Matthew Gardiner <mg11 at csr.com
>> <mailto:mg11 at csr.com>> wrote:
>>
>> Based on some recent investigation, it looks as if I won't need
>> to modify the CoreDefinition structure of ArchSpec.cpp. In a
>> local change, I've added specification for the kalimba variants
>> in the SubArchType of llvm::Triple. So it's now possible for me
>> to implement
>>
>> uint32_t ArchSpec::GetCodeByteSize() const
>> uint32_t ArchSpec::GetDataByteSize() const
>>
>> by inspection of subarch field of the triple contained in ArchSpec.
>>
>> However, I'd still appreciate some feedback on a more conceptual
>> level regarding this proposal.
>>
>> thanks
>> Matt
>>
>> Matthew Gardiner wrote:
>>
>> Hi folks,
>>
>> One of the challenges that I need to resolve regarding
>> debugging kalimba processors, is that certain variants have
>> different notions of the size (in bits) of a byte, compared
>> to a lot of more mainstream processors. What I'm referring to
>> is the size of a minimum addressable unit, when the processor
>> accesses memory. For example, on a kalimba architecture
>> version 3, a "byte" (minimum addressable unit) from the data
>> bus is 24-bits, so if the processor reads from address 8001
>> it reads 24-bits, and from address 8002 the next 24-bits are
>> read, and so on... (this also means that for this variant a
>> char, int, long, pointer are 24-bits in size). For kalimba
>> architecture version 4, however, we have the minimum
>> addressable unit being 8-bits, and correspondingly more
>> "conventional" sizes for primitive types.
>>
>> I imagine that this will effect the kalimba lldb port is
>> various ways. The most obvious one, and hence the one I'd
>> like to solve first, is that way in which raw memory
>> read/write are implemented. As an example when I ask lldb to
>> read 4 "bytes" (addressable units worth of data) from a
>> kalimba with 8-bit bytes I expect to see this:
>>
>> (lldb) memory read --count 4 0x0328
>> 0x00000328: 00 07 08 08 ....
>> (lldb)
>>
>> However if target processor has 24-bit bytes then I expect
>> the same query to yield the following answer:
>>
>> (lldb) memory read --count 4 0x0328
>> 0x00000328: 000708 080012 095630 023480
>> ....
>> (lldb)
>>
>> Just considering the above scenario leads me to believe that
>> my first challenge is arranging for the remote protocol
>> implementation (currently Process/gdb-remote et al) to assume
>> Nx host bytes (N being a target-specific value) for each
>> target byte accessed, and for the memory read and formatting
>> code (above) to behave correctly, given the discrepancy
>> between host and target byte sizes. I guess I'll see many
>> other challenges - for example, frame variable decode, stack
>> unwind etc. (but since *those* challenges require work on
>> clang/llvm backend, and CSR have no llvm person yet, I want
>> to concentrate on raw memory access first...)
>>
>> For an added complication (since kalimba is a harvard
>> architecture) certain kalimba variants have differing
>> addressable unit sizes for memory on the code bus and data
>> bus. Kalimba Architecture 5 has 8-bit addressable code, and
>> 24-bit addressable data...
>>
>> My initial idea for how to start to address the above
>> challenge is to augment the CoreDefinition structure in
>> ArchSpec.cpp as follows:
>>
>> struct CoreDefinition
>> {
>> ByteOrder default_byte_order;
>> uint32_t addr_byte_size;
>> uint32_t min_opcode_byte_size;
>> uint32_t max_opcode_byte_size;
>> + uint32_t code_byte_size;
>> + uint32_t data_byte_size;
>> llvm::Triple::ArchType machine;
>> ArchSpec::Core core;
>> const char * const name;
>> };
>>
>> Where code_byte_size and data_byte_size would specify the
>> size in host (8-bit) bytes the sizes of the minimum
>> addressable units on the referenced architectures. So, e.g.
>> For kalimba 3, with 24-bit data bytes and 32-bit code bytes
>> we'd have data_byte_size=3 and code_byte_size=4
>> For kalimba 4, with 8-bit data bytes and 8-bit code bytes
>> we'd have data_byte_size=1 and code_byte_size=1
>>
>> So, then I'd update the g_core_definitions array within
>> ArchSpec.cpp accordingly, such that all non-kalimbas would
>> have 1 as the setting for the new datas and the kalimba
>> entries would have those fields made to match the architectures.
>>
>> The ArchSpec class would then require the following
>> accessors: uint32_t GetCodeByteSize() and uint32_t
>> GetDataByteSize(); to supply client code with the required
>> hints to correctly implement memory accesses.
>>
>> My next plan would be to "massage" the code in the execution
>> flow from an (lldb) memory read invocation through to the
>> gdb-remote comms until I see the memory read examples I
>> illustrated above, working for 8-bit and 24-bit data kalimba
>> targets.
>>
>> I'd appreciate all comments and opinions as to what I've
>> described above from the lldb community. Basically, I'm
>> curious as to what people think of the whole concept, e.g.
>>
>> "You can't possibly do that, so many other architectures have
>> 8-bit bytes, and so this proposal would make them harder to
>> enhance, for the benefit of (currently) just kalimba"
>> "Yes, that's a good idea, lldb can accommodate the most
>> unusual of architectures"
>>
>> And I'm also interested in technical comments, e.g. should an
>> instance of CoreDefinition be added to ArchSpec, or is just
>> adding the extra byte-size attributes sufficient... or if
>> anyone thinks that modifying gdb-remote is a bad idea, and
>> that I should be creating kalimba process abstractions (and
>> factor out the common code)?
>>
>> thanks
>> Matt
>>
>>
>>
>> Member of the CSR plc group of companies. CSR plc registered
>> in England and Wales, registered number 4187346, registered
>> office Churchill House, Cambridge Business Park, Cowley Road,
>> Cambridge, CB4 0WZ, United Kingdom
>> More information can be found at www.csr.com
>> <http://www.csr.com/>. Keep up to date with CSR on our
>> technical blog, www.csr.com/blog <http://www.csr.com/blog>,
>> CSR people blog, www.csr.com/people
>> <http://www.csr.com/people>, YouTube,
>> www.youtube.com/user/CSRplc
>> <http://www.youtube.com/user/CSRplc>, Facebook,
>> www.facebook.com/pages/CSR/191038434253534
>> <http://www.facebook.com/pages/CSR/191038434253534>, or
>> follow us on Twitter at www.twitter.com/CSR_plc
>> <http://www.twitter.com/CSR_plc>.
>> New for 2014, you can now access the wide range of products
>> powered by aptX at www.aptx.com <http://www.aptx.com/>.
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu <mailto:lldb-dev at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>>
>> To report this email as spam click
>> https://www.mailcontrol.com/sr/nergAztaJijGX2PQPOmvUs3i7gRn49Hg+ad6BErjJilinO59sjEAHiLtU+YE5asZgsAG+GH7HC!3KeH4!zzvzA==
>> <https://www.mailcontrol.com/sr/nergAztaJijGX2PQPOmvUs3i7gRn49Hg+ad6BErjJilinO59sjEAHiLtU+YE5asZgsAG+GH7HC%213KeH4%21zzvzA==>
>> .
>>
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu <mailto:lldb-dev at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>>
>>
>>
>> --
>> Todd Fiala | Software Engineer | tfiala at google.com
>> <mailto:tfiala at google.com> | 650-943-3180
>>
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu <mailto:lldb-dev at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
More information about the lldb-dev
mailing list