Re: Stack protector: leak of guard's address on stack

2018-04-27 Thread Thomas Preudhomme
ing a CVE for that issue? Best regards, Thomas On 27 April 2018 at 14:38, Jakub Jelinek wrote: > On Fri, Apr 27, 2018 at 02:31:25PM +0100, Thomas Preudhomme wrote: > > On x86 yes, it's actually done in the same instruction that's doing the > > comparison if I'm not

Re: Stack protector: leak of guard's address on stack

2018-04-27 Thread Thomas Preudhomme
n 27 April 2018 at 13:22, Jakub Jelinek wrote: > On Fri, Apr 27, 2018 at 01:17:50PM +0100, Thomas Preudhomme wrote: > > It's not the canari which is spilled in this case, but the address to the > > canari. Which means an attacker could make it point to something else > than &g

Re: Stack protector: leak of guard's address on stack

2018-04-27 Thread Thomas Preudhomme
It's not the canari which is spilled in this case, but the address to the canari. Which means an attacker could make it point to something else than the real canari. On 27 April 2018 at 13:16, Jakub Jelinek wrote: > On Thu, Apr 19, 2018 at 06:17:26PM +0100, Thomas Preudhomme wrote:

Re: Stack protector: leak of guard's address on stack

2018-04-27 Thread Thomas Preudhomme
Hi there, Any objection to filing a CVE for that? Best regards, Thomas On 19 April 2018 at 18:17, Thomas Preudhomme wrote: > Hi, > > For stack protector to be robust, at no point in time the guard against > which the canari is compared must be spilled to the stack. This is a

Stack protector: leak of guard's address on stack

2018-04-19 Thread Thomas Preudhomme
Hi, For stack protector to be robust, at no point in time the guard against which the canari is compared must be spilled to the stack. This is achieved by having dedicated insn pattern for setting the canari and comparing it against the guard which doesn't reflect at RTL what is happening. However

Re: Cortex-r52 FP double precision

2018-01-31 Thread Thomas Preudhomme
y why ARMv8-R is not listed in t-rmprofile multilib ? Alex On Fri, Jan 26, 2018 at 9:25 PM, Thomas Preudhomme wrote: That or just use -mfpu=auto (as in -mcpu=cortex-r52 -mfpu=auto -mfloat-abi=(softfp|hard)). Best regards, Thomas On 26/01/18 16:44, Alexander Fedotov wrote: Thank you Thomas

Re: Cortex-r52 FP double precision

2018-01-26 Thread Thomas Preudhomme
n Fri, Jan 26, 2018 at 12:52 PM, Thomas Preudhomme wrote: Hi Alexander, As mentioned in [1], Arm Cortex-R52 can have either single precision or double precision + Neon. This is reflected in GCC 8 by -mcpu=cortex-r52 defaulting to the latter (double precision + Neon) and -mcpu=cortex-r52+nofp.dp

Re: Cortex-r52 FP double precision

2018-01-26 Thread Thomas Preudhomme
Hi Alexander, As mentioned in [1], Arm Cortex-R52 can have either single precision or double precision + Neon. This is reflected in GCC 8 by -mcpu=cortex-r52 defaulting to the latter (double precision + Neon) and -mcpu=cortex-r52+nofp.dp giving you the former (single precision). [1] https://

Re: glue file built with compiler in PATH in out of tree testing

2017-12-07 Thread Thomas Preudhomme
On 07/12/17 15:17, Joseph Myers wrote: On Thu, 7 Dec 2017, Thomas Preudhomme wrote: That seems to go counter to the --prefix option of contrib/test_installed which is meant to test a compiler at an arbitrary path. This suggest the compiler is not expected to be in PATH or in any dejagnu

Re: glue file built with compiler in PATH in out of tree testing

2017-12-07 Thread Thomas Preudhomme
Hi Joseph, On 06/12/17 17:53, Joseph Myers wrote: On Wed, 6 Dec 2017, Thomas Preudhomme wrote: == problem == I'm not sure where is the proper place to fix this. Obviously setting CC_FOR_TARGET in contrib/test_installed or when calling runtest manually would work but I wonder if this

glue file built with compiler in PATH in out of tree testing

2017-12-06 Thread Thomas Preudhomme
Hi, TL;DR: where to tell dejagnu about the compiler to use for building testglue? == context == I've just found out that testglue.c is built using the compiler in PATH when doing out of tree testing rather than using the one specified by GCC_UNDER_TEST (or other *_UNDER_TEST). This is because

Re: r247646 (likely) causing bootstrap error

2017-05-05 Thread Thomas Preudhomme
Sorry my apologies. I see that Nathan already fixed it. Must have slipped in during a conflict resolution during one of the many rebase between testing and commit approval. Best regards, Thomas On 05/05/17 18:27, Martin Sebor wrote: I see the following error during bootstrap on x86_64 config

Users of tm_p.h and emit-rtl.h now need to include memmodel.h

2016-10-13 Thread Thomas Preudhomme
Attention everyone, I've just committed a patch to move MEMMODE_* macros and enum memmodel definitions from coretypes.h to memmodel.h. As a consequence, people who include emit-rtl.h anywhere or include tm_p.h in the middle end need to include memmodel.h beforehand. This is because emit-rtl.h

RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat

2014-03-04 Thread Thomas Preudhomme
Le 2014-03-04 19:14, Matthew Fortune a écrit : Hi Thomas, Hi Matthew, Do you particularly need a switch for this? You could view this as simply relaxing the ABI requirements of a module, a switch would only serve to enforce the need for a compatible ABI and error if not. If you build somethi

[RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat

2014-03-03 Thread Thomas Preudhomme
[Please CC me as I'm not subscribed to this list] Hi there, I'm currently working on adding a switch to check whether public function involve float parameters or return values. Such a check would be useful for people trying to write code that is compatible with both base standard (softfloat)