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

[Matthew Gardiner]

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.