[Lldb-commits] [PATCH] Very minimal non-8-bit byte support for diverse kalimba architectures

jingham at apple.com jingham at apple.com
Fri Sep 26 09:05:07 PDT 2014


Greg is out on vacation for a week.  This looks fairly straightforward.  There used to be architectures with weird byte sizes like 9 or 12 bits - gdb had some support for this.  Choosing to express the number of bits per byte as a multiple of 8 makes it impossible to support this situation.  OTOH I'm not sure how much that matters now-a-days.

Jim

> On Sep 26, 2014, at 6:33 AM, Matthew Gardiner <mg11 at csr.com> wrote:
> 
> Hi clayborg, tfiala,
> 
> This diff contains some initial work in getting lldb to debug non-8-bit byte architectures (currently only CSRs kalimba 5 architecture). I appreciate that it won't interest non-CSR people greatly but I thought it polite to place up for review prior to commit.
> 
> Key points:
> * target_byte_size is added to DataExtractor for subsequent use as a formatting hint
> * target_byte_size is added to Section class, since section sizes are in host bytes, and hence a multiplier is required to calculate correct offsets
> * ObjectFileELF.cpp slightly modified to create sections with correct bytesize (kalimba annoyingly has differing bytesizes in code and data)
> * ObjectFile.cpp ReadSection modified regarding bytesizes and offsets
> * CommandObjectMemory changed can to allocate larger read buffers for mentioned architectures and to advise DataExtractor accordingly
> * DataExtractor when printing bytes, consume target_byte_size number of bytes from host buffer for each byte printed.
> 
> Other changes in the diff:
> * removal eCore_kalimba enumerant (specify each kalimba variant separately)
> * support better recognition of kalimba3/4/5
> * In ArchSpec lie about kalimba 24-bit bytes. Say they are 32-bit since 24-bit bytes are much harder to express on regular Intel PC platforms etc.
> 
> This diff is very, very minimal regarding getting non-8-bit byte architectures supported in lldb. However, for me, the only practical way is to work incrementally - lldb is far too big to change in one go, in this area. For example, only the count option is currently supported for memory read, I've not looked in any depth at -f format options.
> 
> http://reviews.llvm.org/D5503
> 
> Files:
>  include/lldb/Core/ArchSpec.h
>  include/lldb/Core/DataExtractor.h
>  include/lldb/Core/Section.h
>  source/Commands/CommandObjectMemory.cpp
>  source/Core/ArchSpec.cpp
>  source/Core/DataExtractor.cpp
>  source/Core/Section.cpp
>  source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
>  source/Plugins/Platform/Kalimba/PlatformKalimba.cpp
>  source/Symbol/ObjectFile.cpp
> <D5503.14112.patch>_______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits




More information about the lldb-commits mailing list