llvm dev - Jun 2014 - [LLVMdev] [cfe-dev] [PATCH] triples for baremetal

Hi Jonathan,

This looks a bit odd. Any reason for the unknown->none conflating in
this way? For most (all) of the ports unknown-elf works the same as
none-elf. I'm also not sure if someone decided to have,
arm-codesourcery-elf that this would still work with the patch.

Thoughts?

-eric

On Tue, Jun 24, 2014 at 7:35 AM, Amara Emerson <amara.emerson at
gmail.com> wrote:
> Hi Jon,
>
> This looks reasonable to me.
>
> Cheers,
> Amara
>
> On 24 June 2014 14:58, Jonathan Roelofs <jonathan at
codesourcery.com> wrote:
>>
>>
>> On 6/23/14, 8:31 AM, David Chisnall wrote:
>>>
>>> On 23 Jun 2014, at 15:13, Renato Golin <renato.golin at
linaro.org> wrote:
>>>
>>>> The main issue with your patch is that it can change user
expected
>>>> behaviour, and I can't tell you what is the expected
behaviour in
>>>> Darwin or BSD. If people usually use "unknown" in
triples, this will
>>>> break their builds. If not, this could break the build of
someone who
>>>> does.
>>
>> Renato,
>>
>> I would like to go this route, providing I can get support from the
>> community that this is the direction we'd all like to take...
I'd rather not
>> make triples more complicated by introducing lots of special cases.
>>
>> Do you know who the right folks are to ask about the SPIR triples?
>>
>>
>> Tim,
>>
>> This patch changes behavior a little for macho_embedded targets (i.e.
from
>> OSType::Unknown to OSType::NoneOS). I see that there is existing code
to
>> transform triples from things like thumbv7-apple-darwin into
>> thumbv7m-apple-unknown-macho. Do you have an expectation to support
users
>> who are using the latter form of triples who would be surprised by the
>> change from thumbv7m-apple-unknown-macho to thumbv7m-apple-none-macho
(i.e.
>> their thumbv7m-apple-unknown-macho builds no longer work)? Is this a
case
>> where all three triples are to mean the same thing?
>>
>>
>>>
>>> I think (Hat: FreeBSD) we only expect to see unknown in the vendor
field
>>> (e.g. i386-unknown-freebsd).  If the OS field is unknown, rather
than
>>> freebsd, then it's not one of ours and we aren't likely to
care.  I don't
>>> really like the way that we conflate OS with ABI, but then I
don't really
>>> like anything about triples...
>>
>> David, thanks!
>>
>>
>> Cheers,
>> Jon
>>
>>>
>>> David
>>>
>>
>> --
>> Jon Roelofs
>> jonathan at codesourcery.com
>> CodeSourcery / Mentor Embedded
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

On 6/24/14, 12:01 PM, Eric Christopher wrote:
> Hi Jonathan,
>
> This looks a bit odd. Any reason for the unknown->none conflating in
> this way?
I'm trying to un-conflate them... What specifically seems odd to you about
it?

IMHO, when a user doesn't explicitly specify that a target's OS is
'none'
(perhaps they left it off, or they explicitly said 'unknown') then they
probably
don't intend to target bare-metal.
> For most (all) of the ports unknown-elf works the same as
> none-elf.
Yes, and so would santas-elf ;)

All three of these examples fall into the same "it doesn't match
anything else
OSType::UnknownOS bucket", and I want to change
that.
> I'm also not sure if someone decided to have,
> arm-codesourcery-elf that this would still work with the patch.
Well, depends on what you mean by 'work', and also what is meant by that
triple.
To me, it means:

     ArchType: arm
     VendorType: CodeSourcery
     OSType: UnknownOS (not bare-metal)
     EnvironmentType: UnknownEnvironment
     ObjectFormatType: elf

If a user wants the baremetal version of that hypothetical triple, my argument 
is that they should say arm-codesourcery-none-elf, and they would get:

     ArchType: arm
     VendorType: CodeSourcery
     OSType: NoneOS
     EnvironmentType: UnknownEnvironment
     ObjectFormatType: elf

Does that make sense?


Cheers,

Jon
>
> Thoughts?
>
> -eric
>
-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded

On 24 June 2014 19:57, Jonathan Roelofs <jonathan at codesourcery.com>
wrote:
> Well, depends on what you mean by 'work', and also what is meant by
that
> triple. To me, it means:
>
>     ArchType: arm
>     VendorType: CodeSourcery
>     OSType: UnknownOS (not bare-metal)
>     EnvironmentType: UnknownEnvironment
>     ObjectFormatType: elf
Isn't that funny that, when we want to come up with a reasonable and
logical "triple", it actually has 5 fields? :)

That's why Clang and LLVM are desperately trying to move away from
triples, into separate flags. But if you separate the default from the
triple handling, we can re-use the default for the separate arguments
in the same way we use for legacy triples.

> Does that make sense?
It does when we control the environment. On legacy systems, not even
the user does. :(

--renato