On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes wrote:
> Trivial update to change the version to 19-ea, and update the single
> reference to the "current release".
>
> Content changes for 19 will follow.
>
> Thanks,
> David
Thanks for the reviews Erik, Jon and Iris!
-
PR: https:/
On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes wrote:
> Trivial update to change the version to 19-ea, and update the single
> reference to the "current release".
>
> Content changes for 19 will follow.
>
> Thanks,
> David
This pull request has now been integrated.
Changeset: 624f3094
Author
On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes wrote:
> Trivial update to change the version to 19-ea, and update the single
> reference to the "current release".
>
> Content changes for 19 will follow.
>
> Thanks,
> David
Marked as reviewed by iris (Reviewer).
-
PR: https://git
On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes wrote:
> Trivial update to change the version to 19-ea, and update the single
> reference to the "current release".
>
> Content changes for 19 will follow.
>
> Thanks,
> David
Marked as reviewed by jjg (Reviewer).
-
PR: https://git.
* erik joelsson:
> Hello Florian,
>
> We still build with glibc 2.12 in the sysroot at Oracle as we still
> support Oracle Linux 6 (which uses glibc 2.12), so I'm afraid we still
> need it.
Fair enough. I will tack another thing to the side of this then. 8->
Thanks,
Florian
Hello Florian,
We still build with glibc 2.12 in the sysroot at Oracle as we still
support Oracle Linux 6 (which uses glibc 2.12), so I'm afraid we still
need it.
/Erik
On 2021-12-13 05:21, Florian Weimer wrote:
It seems that building against glibc 2.12 is still supported. Is this
somethin
On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes wrote:
> Trivial update to change the version to 19-ea, and update the single
> reference to the "current release".
>
> Content changes for 19 will follow.
>
> Thanks,
> David
Looks good to me.
-
Marked as reviewed by erikj (Reviewe
It seems that building against glibc 2.12 is still supported. Is this
something that is still needed?
I'm mostly concerned with this fallback code on x86-64:
// Unfortunately we have to bring all these macros here from vsyscall.h
// to be able to compile on old linuxes.
#define __NR_vgetcpu 2
On Mon, 13 Dec 2021 09:56:41 GMT, Andrew Haley wrote:
>> You can support one without the other.
>> The architecture allows you to have one without the other.
>> The GCC flag is an enum of "none|standard|pac-ret[+leaf]|bti", with some of
>> them changing depending on which cpu you specify to -mcp
On Mon, 13 Dec 2021 09:50:26 GMT, Alan Hayward wrote:
> You can support one without the other. The architecture allows you to have
> one without the other. The GCC flag is an enum of
> "none|standard|pac-ret[+leaf]|bti", with some of them changing depending on
> which cpu you specify to -mcpu
On Sun, 12 Dec 2021 10:19:30 GMT, Andrew Haley wrote:
>> `-mbranch-protection` switches on both PAC-RET and BTI. This PR only covers
>> a use of PAC that looks very ROP-focused to me.
>
> True, because we don't (yet) support BTI. Is there any point having two
> separate flags for BTI and PAC-RE
11 matches
Mail list logo