This is an archive of the discontinued LLVM Phabricator instance.

Very minimal non-8-bit byte support for diverse kalimba architectures
ClosedPublic

Authored by mg11 on Sep 26 2014, 6:33 AM.

Details

Reviewers
clayborg
tfiala
Summary

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.

Diff Detail

Event Timeline

mg11 updated this revision to Diff 14112.Sep 26 2014, 6:33 AM
mg11 retitled this revision from to Very minimal non-8-bit byte support for diverse kalimba architectures.
mg11 updated this object.
mg11 edited the test plan for this revision. (Show Details)
mg11 added reviewers: clayborg, tfiala.
mg11 added a subscriber: Unknown Object (MLST).

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

mg11 added a comment.Sep 28 2014, 11:42 PM

@Jim
Regarding architectures with bytes whose size aren't a multiple of 8-bits, I believe these must be rare beasts indeed nowadays. Apart a colleague mentioning a TI processor (TMS320C5517) and CCL/CSRs XAP processor, both of which are 16-bit, I know only of the Kalimba, as a current-day processor, with non-8-bit-bytes. Well, should any even more exotic creatures show up, then at least I'll have started to pace the way for them...

In D5503#6, @mg11 wrote:

@Jim
Regarding architectures with bytes whose size aren't a multiple of 8-bits, I believe these must be rare beasts indeed nowadays. Apart a colleague mentioning a TI processor (TMS320C5517) and CCL/CSRs XAP processor, both of which are 16-bit, I know only of the Kalimba, as a current-day processor, with non-8-bit-bytes. Well, should any even more exotic creatures show up, then at least I'll have started to pace the way for them...

Indeed. I know of a few devices apart from Kalimba that have non 8bit bytes, but they are all at least multiples of 8-bits in byte implementation.

clayborg accepted this revision.Oct 6 2014, 2:57 PM
clayborg edited edge metadata.

Looks good.

This revision is now accepted and ready to land.Oct 6 2014, 2:57 PM
tfiala accepted this revision.Sep 23 2015, 10:40 PM
tfiala edited edge metadata.

This review is mighty stale, but going through my differentials I saw it was still around. It looked good for the time.

tfiala closed this revision.Oct 10 2015, 9:21 PM

I'm going ahead and closing this one out. It either went in or is not interesting to the author any more. Last ping was over a couple weeks ago.