[lldb-dev] [RFC] ArchSpec

[Stephen Wilson]

*,


The ArchSpec class has been giving me a few problems on linux lately.
There were two main issues:

    1) The default "personality" for an ArchSpec is MachO.  This
       assumption was causing a few issues when the linux plugins were
       being handed an ArchSpec they could not deal with.

    2) We have an llvm::Triple embedded in an ArchSpec.  For MachO
       ArchSpec's it makes sense to have a vendor-os component of
       "apple-darwin" as default, but for ELF there is no way to guess
       what the operating system might be.  Since we do not have the
       logic in LLDB yet to create an ArchSpec's with the appropriate OS
       bits resolved we were failing during plugin lookup on linux.

So basically what I think we need is:

    A) An ArchSpec which does not assume much.

    B) An ArchSpec that is free of "magic" cpu type and subtype numbers,
       feature flags, etc.  Use generic values like ArchSpec::CPU,
       llvm::Triples, or plain strings instead.

    C) A bit more logic at the points where ArchSpecs are instantiated
       to figure out what the ArchSpec should be.

Attached is a almost entirely rewritten ArchSpec that tries to address
point A, but with a view towards implementing point B down the road.  I
have been testing it on linux with a few modifications to LLDB that help
with point C, but before I do any more work on this I thought I'd run
what I have past everyone first.

This "new" ArchSpec certainly borrows from the original version and
looks similar as far as the API goes.  However, some things have been
moved around to help make a migration to a generic interface a bit
easier.

The major differences are:

  - Constructor that accepts an llvm::Triple as argument.

  - No more constructors that take cpu or cpu subtypes as arguments.

  - The cpu subtype is settable via SetCPUSubtype or implicitly set via
    an architecture name.  We could also resolve it if given a detailed
    llvm::Triple.  Eventually it would be nice to use a generic
    enumeration value here.

  - The feature flags are now independent of the cpu subtype.
    Eventually it would be nice to provide a set of generic flags to
    provide things like ABI info and anything else we might need.

  - The implementation is fairly generic.  It is driven by table
    lookups.  There are only a few places where the code does a "switch"
    or an "if" over particular values.  Eventually the table lookups
    could be implemented over "generic" values instead of the current
    "magic" ones.

  - A little bit more work is done to try and ensure the ArchSpec
    remains in a consistent state.  All mutators can fail now if the
    requested combination of properties does not make sense (except in
    the case of feature flags as they are not yet modeled, and we can
    still override the default endianess of an architecture).

  - ArchSpec::AsCString has been reimplemented to use a caller supplied
    buffer.  Main reason being the old implementation was not thread
    safe.  For the common case where all you need is an architecture
    name (instead of the fancy "macho-6-4" style triples)
    ArchSpec::GetArchitectureName is provided.



Please not that this code is only lightly tested.  All thoughts/comments
appreciated.


Thanks!

--
steve


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ArchSpec.h
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20110218/01c4a411/attachment.h>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ArchSpec.cpp
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20110218/01c4a411/attachment.ksh>