On 07/21/2017 12:17 PM, Wilco Dijkstra wrote:
> Jeff Law wrote:
>
>> Examples please? We should be probing the outgoing args at the probe
>> interval once the total static frame is greater than 3k. The dynamic
>> space should be probed by generic code.
>
> OK, here are a few simple example
Jeff Law wrote:
> Examples please? We should be probing the outgoing args at the probe
> interval once the total static frame is greater than 3k. The dynamic
> space should be probed by generic code.
OK, here are a few simple examples that enable a successful jump of the stack
guard despit
On 07/19/2017 11:53 AM, Wilco Dijkstra wrote:
> Hi Jeff,
>
> There is an issue with your AArch64 patch, it fails to apply properly and does
> so silently using 'patch'. I also noticed some odd control characters in the
> other
> patches, but they didn't appear to fail (or at least everything buil
Hi Jeff,
There is an issue with your AArch64 patch, it fails to apply properly and does
so silently using 'patch'. I also noticed some odd control characters in the
other
patches, but they didn't appear to fail (or at least everything builds).
Anyway with -Ofast -static the overall codesize incr
So this patch has changed considerably since V1 as well.
First, we no longer track the bulk of the register stores in the
prologue. Those may be separately shrink wrapped and thus not executed
on all paths and as such are not candidates for implicit probes.
Second, per the discussions we've had
On 07/17/2017 04:42 PM, Wilco Dijkstra wrote:
> Jeff Law wrote:
>> On 07/17/2017 05:27 AM, Wilco Dijkstra wrote:
>
>>> A minimum guard size of 64KB seems reasonable even on systems with
>>> 4KB pages. However whatever the chosen guard size, you cannot defend
>>> against hostile code. An OS can
Jeff Law wrote:
> On 07/17/2017 05:27 AM, Wilco Dijkstra wrote:
> > A minimum guard size of 64KB seems reasonable even on systems with
> > 4KB pages. However whatever the chosen guard size, you cannot defend
> > against hostile code. An OS can of course increase the guard size well
> > beyond
On Mon, Jul 17, 2017 at 09:51:40AM -0600, Jeff Law wrote:
> On 07/16/2017 12:36 PM, Trevor Saunders wrote:
> >>> On the other hand if probing is fast enough that it can be on by default
> >>> in gcc there should be much less of it. Even if you did change the ABI
> >>> to require probing it seems u
On 07/16/2017 12:36 PM, Trevor Saunders wrote:
>>> On the other hand if probing is fast enough that it can be on by default
>>> in gcc there should be much less of it. Even if you did change the ABI
>>> to require probing it seems unlikely that code violating that
>>> requirement would hit problem
On Mon, Jul 17, 2017 at 09:24:27AM -0600, Jeff Law wrote:
> >> While I'm not really comfortable with the 2k/2k split in general, I
> >> think I can support it from a Red Hat point of view -- largely because
> >> we use 64k pages in RHEL. So our guard is actually 64k. Having a
> >> hostile call ch
On 07/17/2017 05:27 AM, Wilco Dijkstra wrote:
> Jeff Law wrote:
>
>> So would a half-half (2k caller/2k callee) split like Florian has
>> proposed work for you? ie, we simply declare a caller that pushes the
>> stack pointer 2k or more into the guard as broken?
>
> My results show using a 4KB gu
Jeff Law wrote:
> So would a half-half (2k caller/2k callee) split like Florian has
> proposed work for you? ie, we simply declare a caller that pushes the
> stack pointer 2k or more into the guard as broken?
My results show using a 4KB guard size is not ideal. 2KB of outgoing
args is too large
On Wed, Jul 12, 2017 at 03:08:28PM -0600, Jeff Law wrote:
> On 07/12/2017 06:47 AM, Trevor Saunders wrote:
> > On Tue, Jul 11, 2017 at 08:02:26PM -0600, Jeff Law wrote:
> >> On 07/11/2017 06:20 PM, Wilco Dijkstra wrote:
> >>> Jeff Law wrote:
> aarch64 is the first target that does not have any
Jakub Jelinek wrote:
> On Wed, Jul 12, 2017 at 12:20:32AM +, Wilco Dijkstra wrote:
> > Therefore even when using a tiny 4K probe size we can safely adjust SP by
> > 3KB
> > before needing an explicit probe - now only 0.6% of functions need a probe.
> > If we choose a proper minimum probe dist
On Wed, Jul 12, 2017 at 12:20:32AM +, Wilco Dijkstra wrote:
> No - like I mentioned before that's not correct nor acceptable as it would
> imply
> that ~70% of functions need a probe at entry. I did a quick run across SPEC
> and
> found the outgoing argument size is > 1024 in just 9 functions
On 07/11/2017 06:20 PM, Wilco Dijkstra wrote:
> Jeff Law wrote:
>> aarch64 is the first target that does not have any implicit probes in
>> the caller. Thus at prologue entry it must make conservative
>> assumptions about the offset of the most recent probed address relative
>> to the stack pointe
On 07/12/2017 06:47 AM, Trevor Saunders wrote:
> On Tue, Jul 11, 2017 at 08:02:26PM -0600, Jeff Law wrote:
>> On 07/11/2017 06:20 PM, Wilco Dijkstra wrote:
>>> Jeff Law wrote:
aarch64 is the first target that does not have any implicit probes in
the caller. Thus at prologue entry it must
On Tue, Jul 11, 2017 at 08:02:26PM -0600, Jeff Law wrote:
> On 07/11/2017 06:20 PM, Wilco Dijkstra wrote:
> > Jeff Law wrote:
> >> aarch64 is the first target that does not have any implicit probes in
> >> the caller. Thus at prologue entry it must make conservative
> >> assumptions about the offs
On 07/11/2017 06:20 PM, Wilco Dijkstra wrote:
> Jeff Law wrote:
>> aarch64 is the first target that does not have any implicit probes in
>> the caller. Thus at prologue entry it must make conservative
>> assumptions about the offset of the most recent probed address relative
>> to the stack pointe
Jeff Law wrote:
> aarch64 is the first target that does not have any implicit probes in
> the caller. Thus at prologue entry it must make conservative
> assumptions about the offset of the most recent probed address relative
> to the stack pointer.
No - like I mentioned before that's not correct
This patch introduces aarch64 -fstack-check=clash prologue support.
aarch64 is the first target that does not have any implicit probes in
the caller. Thus at prologue entry it must make conservative
assumptions about the offset of the most recent probed address relative
to the stack pointer.
Ho
21 matches
Mail list logo
