[lldb-dev] Advice on debugging DSP and Harvard architectures

[Abid, Hafiz]

> So is the "add an offset" technique still the best way forward to solve this
> problem? How about adding a new request (along with a query request to
> interrogate the stub for support) for code reads - is this an option?
> (If so, I'd be happy to do the work...)

If you do this, then you will probably have to add the knowledge of whether you
are reading a code memory or a data memory into the remote protocol layer and
its callers. I think it would be more invasive change.

One more issue that you may face is pointer residing in data memory
but pointing to entities in code memory. The dwarf attribute DW_AT_address_class
can be used to provide the required debug information. But you may need to
add/improve the address space handling in lldb.


> So, summarising, I'm wondering if anyone has any ideas/advice on the above
> questions, that is, using lldb on harvard architectures and on non-standard-
> byte-size architectures.

Do you have a clang port for your dsp? I wonder if you would have issues with
expression parsing without clang knowing the details of your dsp. I may be
completely wrong though.

Regards,
Abid

> -----Original Message-----
> From: lldb-dev-bounces at cs.uiuc.edu [mailto:lldb-dev-bounces at cs.uiuc.edu]
> On Behalf Of Matthew Gardiner
> Sent: 30 May 2014 07:45
> To: lldb-dev at cs.uiuc.edu
> Subject: [lldb-dev] Advice on debugging DSP and Harvard architectures
> 
> Hi folks,
> 
> I have been researching using lldb and a custom gdbserver stub to debug
> some of our processors. I have already played with ArchSpec.h/.cpp/Elf.h to
> add a processor definition, and since our tools output DWARF information,
> have already managed to use lldb to dump line tables.
> 
> On the gdbserver side of things I'm managing to get register read and writes
> to work, but I fear an issue may arise in memory reads, since the DSPs
> Harvard architecture dictates separate address spaces. Therefore, when we
> attempt to read 1) code memory to disassemble, and 2) data memory (for
> variables decode etc.) the stub will receive an 'm' request but interpretation
> of the address field is ambiguous, as it could refer to either the CODE or
> DATA bus.
> 
> It seems that the commonly adopted approach so far (i.e. with gdb) is to
> produce a larger single address space by adding an offset to the memory
> address and arranging for the stub to interpret the presence/absence of the
> offset and act accordingly. (I have indeed read of this approach being
> employed for AVR processors). This technique is workable (provided the
> DSPs continue to have fairly small physical memories), but certainly has
> drawbacks i) changes to the debugger to add the offset, ii) increased packet
> size (e.g. all code read addresses having highest bit set), iii) increased
> compression/decompression due to RLE on the response.
> 
> So is the "add an offset" technique still the best way forward to solve this
> problem? How about adding a new request (along with a query request to
> interrogate the stub for support) for code reads - is this an option?
> (If so, I'd be happy to do the work...)
> 
> Another issue which I'm looking at, is that some of our DSPs have 24-bit
> bytes. (That is, a single data address reads back 24-bits of data). At this
> moment in time, I'm not altogether sure just how problematic this will be for
> lldb. I've looked into the g_core_definitions table, and I can't see an entry for
> this, (presumably it would either be a 1 or an 8, depending whether it's
> measured in host bytes, or bits). I assume that all the architectures in the
> table so far have 8-bit bytes. Is anyone else out there looking at using lldb to
> debug targets with non-8-bit bytes?
> 
> So, summarising, I'm wondering if anyone has any ideas/advice on the above
> questions, that is, using lldb on harvard architectures and on non-standard-
> byte-size architectures.
> 
> All comments welcome,
> Matthew Gardiner
> 
> 
> 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. Keep up to date
> with CSR on our technical blog, www.csr.com/blog, CSR people blog,
> www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook,
> www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
> www.twitter.com/CSR_plc.
> New for 2014, you can now access the wide range of products powered by
> aptX at www.aptx.com.
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev