Re: [PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

[Szabolcs Nagy via cfe-commits]

The 08/10/2020 10:03, Momchil Velikov via Phabricator wrote:
> chill added a comment.
> 
> In D80791#2196598 , @nsz wrote:
> 
> > the assumption is that the intended branch protection is implied via 
> > cmdline flags for the tu and function attributes are only used in source 
> > code for some hack.
> 
> I don't share this assumption. I find it just as valid to control the PAC/BTI 
> with things like:
> 
>   #ifdef ENABLE_BTI
>   #define BTI_FUNC __attribute__((target("branch-protection=bti")))
>   #else
>   #define BTI_FUNC
>   
>   BTI_FUNC void foo() { ...
>   BTI_FUNC int bar() { ...
> 
> without using any command-line option other than `-DENABLE_BTI=1`.
> 

i think that cannot work.

the implementation is free to inject arbitrary code into
user code so if the user does not tell the implementation
that it wants the entire tu to be bti safe then non-bti
code can end up in there. (e.g. ctor of an instrumentation
that is not realated to any particular function with the
bti marking)

> 
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D80791/new/
> 
> https://reviews.llvm.org/D80791
> 

-- 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: D40673: Add _Float128 as alias to __float128 to enable compilations on Fedora27/glibc2-26

[Szabolcs Nagy via cfe-commits]

On 13/01/18 12:33, Blower, Melanie wrote:
>> -Original Message-
>> From: Szabolcs Nagy via Phabricator [mailto:revi...@reviews.llvm.org]
>> Sent: Friday, January 12, 2018 3:18 PM 
>>
>> nsz added a comment.
>>  
>>
>> it is not clear to me from the original bug report what "fedora 27 workloads"
>> break because of the lack of _Float128 type on x86.  The glibc headers refer 
>> to
>> _Float128, but normal include should not break unless the compiler claims to 
>> be
>>> =gcc-7 or somebody explicitly requested the _Float128 support.
> [Blower, Melanie] I was building open source projects like ffmpeg, linux from 
> scratch, and others. I was incorrect in my original post, I was using a 
> patched compiler which led to _Float128 being exposed. In an unpatched clang 
> this problem doesn't arise.  I regret the lack of care taken in my analysis 
> of the problem.

then please revert the related patches.
(or finish the _Float128 support).

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [musl] Re: [gentoo-musl] Re: Add support for musl-libc on Linux

[Szabolcs Nagy via cfe-commits]

* Lei Zhang  [2016-06-20 18:59:20 +0800]:
> 2016-06-20 17:37 GMT+08:00 Peter Smith :
> > - isTargetEHABICompatible()
> > I'm making the assumption that musl supports the ARM exceptions EHABI,
> > if so you'll want to add MUSL and MUSLHF here.
> 
> I'm not 100% sure about this. Could some insider from musl confirm this?

musl is ehabi agnostic.

ehabi and libc should be independent.

throwing exceptions across libc boundary is undefined
behaviour, all ehabi support is in the compiler runtime.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [musl] Re: [gentoo-musl] Re: Add support for musl-libc on Linux

[Szabolcs Nagy via cfe-commits]

* Rafael Esp?ndola  [2016-06-13 17:00:17 -0400]:
> Do you need someone to commit it for you?
> On Jun 13, 2016 9:50 AM, "Lei Zhang via cfe-commits" <
> > http://git.alpinelinux.org/cgit/aports/plain/main/clang/clang-0004-Add-musl-targets-and-dynamic-linker.patch
> >
> > This looks neat :)

the dynamic linker names need to be updated (ppc64*, mips64*
mips*-sf are missing) and it defaults to x86_64 which can
be bad.

there is some musl setting already for mips in the driver
which should probably be fixed.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[Szabolcs Nagy via cfe-commits]

* H.J. Lu  [2016-02-08 11:24:53 -0800]:
> I created a mailing list to discuss Linux specific,.processor independent
> modification and extension of generic System V Application Binary Interface:
> 
> https://groups.google.com/d/forum/linux-abi
> 
> I will start to document existing Linux extensions, like STT_GNU_IFUNC.
> I will propose some new extensions soon.
> 

seems to require a registered email address at google.
(and the archive does not work from any console based browser
or using direct http get tools.)

the kernel seems to have a lot of mailing lists, may be
they can handle this list too?

thanks
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits