Abid, Hafiz wrote:
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.
Yes, the change would be invasive. I was assuming that all regular
accesses for memory reads/writes would be targeting the DATA bus, except
for those reads required for the disassembler, which would be CODE
reads. However, your mention of a function pointer breaks this
assumption somewhat.
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.
We don't have such a clang port as yet. There is some talk here of
providing an LLVM backend for our dsp at some stage, though.
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. 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