[Lldb-commits] [PATCH] Update ObjectFileELF to detect ELF triple based on ELF notes and the ELF header.

[Todd Fiala]

Okay cool, thanks!


On Thu, Jun 26, 2014 at 3:39 PM, Greg Clayton <gclayton at apple.com> wrote:

>
> > On Jun 26, 2014, at 3:03 PM, Todd Fiala <tfiala at google.com> wrote:
> >
> > Hey Greg,
> >
> > On Thu, Jun 26, 2014 at 2:52 PM, Greg Clayton <gclayton at apple.com>
> wrote:
> > A few things with respect to triple comparison:
> >
> > The strings really shouldn't be compared, but the arch/vendor/os enums
> should be. You might also have a "unspecified 'unknown'" or a "specified
> 'unknown'".
> >
> > For example if you type:
> >
> > (lldb) file --arch x86_64 ...
> >
> > The triple will be:
> >
> > arch = x86_64
> > vendor = "unspecified 'unknown'"
> > os = "unspecified 'unknown'"
> >
> > But if you type:
> >
> >
> > (lldb) file --arch x86_64-unknown-unknown ...
> >
> > The triple will be:
> >
> > arch = x86_64
> > vendor = "specified 'unknown'"
> > os = "specified 'unknown'"
> >
> > Is there a way to mark just the vendor portion as "unspecified
> 'unknown'" without having to use the string form?
>
> Yes
>
> llvm::Triple t;
>
>
> t.setArchName("x86_64")
> t.setVendor(llvm::Triple::Unknown); // Don't set it by string if you want
> "unspecified 'unknown'
> t.setOSName("freebsd9.1)
>
> >  I have a code path where I want to literally clear it meaning "I really
> don't know what it is, but I know it's not what it is currently set to..."
>
> You might also be able to set to the empty string and it might keep the
> string value empty (check that "t.getVendorName()" returns the empty string
> and the "t.getVendor()" returns llvm::Triple::Unknown).
>
>
> > (I hit that when the arch was defaulting to x86_64-apple-{something} but
> I was refining the vendor idea of a Linux x86_64 elf file based on note
> content).
> >
> >
> >
> >
> > --
> > Todd Fiala |   Software Engineer |     tfiala at google.com |
> 650-943-3180
> >
>
>


-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20140626/75560989/attachment.html>