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
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
