Re: [pypy-dev] asmgcc versus shadowstack

[Maciej Fijalkowski]

hi armin

I don't have very deep opinions - but I'm worried about one particular
thing. GCC tends to change its IR with every release, would be parsing
this not be a nightmare that has to be updated with each new release
of gcc?

On Mon, May 30, 2016 at 9:18 AM, Armin Rigo  wrote:
> Hi all,
>
> Recently, we've got a few more of the common bug report "cannot find
> gc roots!".  This is caused by asmgcc somehow failing to parse the
> ".s" files produced by gcc on Linux.
>
> I'm investigating what can be done to improve the situation of asmgcc
> in a more definitive way.  There are basically two solutions:
>
>
> 1) we improve shadowstack.  This is the alternative to asmgcc, which
> is used on any non-Linux platform already.  So far it is around 10%
> slower than asmgcc.
>
> 2) we improve asmgcc by finding some better way than parsing assembler files.
>
>
> I worked during the past month in the branch "shadowstack-perf-2".
> This gives a major improvement on the placement of pushing and popping
> GC roots on the shadow stack.  I think it's worth merging that branch
> in any case.  On x86, it gives roughly 3-4% speed improvements; I'd
> guess on arm it is slightly more.  (I'm comparing the performance
> outside JITted machine code; the JITted machine code we produce is
> more similar.)
>
> The problem is that asmgcc used to be ~10% better.  IMHO, 3-4% is not
> quite enough to be happy and kill asmgcc.  Improving beyond these 3-4%
> seems to require some new ideas.
>
>
> So I'm also thinking about ways to fix asmgcc more generally, this
> time focusing on Linux only; asmgcc contains old code that tries to
> parse MSVC output, and I bet we tried with clang at some point, but
> these attempts both failed.  So let's focus on Linux and gcc only.
>
> Asmgcc does two things with the parsed assembler: it computes the
> stack size at every point, and it tracks some marked variables
> backward until the previous "call" instruction.
>
> I think we can assume that the version of gcc is not older than, say,
> the one on tannit32 (Ubuntu 12.04), which is gcc 4.6.  At least from
> that version, both on x86-32 and x86-64, gcc will emit "CFI
> directives" (https://sourceware.org/binutils/docs/as/CFI-directives.html).
> These are a saner way to get the information about the current stack
> size.
>
> About the backward tracking, we need to have a complete understanding
> of all instructions, even if e.g. for any xmm instruction we just say
> "can't handle GC pointers".  The backward tracking itself is often
> foiled because the assembler is lacking a way to know clearly "this
> call never returns" (e.g. calls to abort(), or to some RPython helper
> that prints stuff and aborts).  In other words, the control flow is
> sometimes hard to get correctly, because a "call" generally returns,
> but not always.  Such mistakes can produce bogus results (including
> "cannot find gc roots!").
>
> What can we do about that?  Maybe we can compile with "-s
> -fdump-final-insns".  This dumps a gcc-specific summary of the RTL,
> which is the final intermediate representation, which looks like it is
> in one-to-one correspondance with the actual assembly.  It would be a
> better input for the backward-tracker, because we don't have to handle
> tons of instructions with unknown effects, and because it contains
> explicit points at which control flow cannot pass.  On the other hand,
> we'd need to parse both the .s and this dump in parallel, matching
> them as we go along.  But I still think it would be better than now.
>
> Of course the best would be to get rid of asmgcc completely...
>
> This mail is meant to be a dump of my current mind's state :-)
>
>
> A bientôt,
>
> Armin.
> ___
> pypy-dev mailing list
> pypy-dev@python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev

[pypy-dev] asmgcc versus shadowstack

[Armin Rigo]

Hi all,

Recently, we've got a few more of the common bug report "cannot find
gc roots!".  This is caused by asmgcc somehow failing to parse the
".s" files produced by gcc on Linux.

I'm investigating what can be done to improve the situation of asmgcc
in a more definitive way.  There are basically two solutions:


1) we improve shadowstack.  This is the alternative to asmgcc, which
is used on any non-Linux platform already.  So far it is around 10%
slower than asmgcc.

2) we improve asmgcc by finding some better way than parsing assembler files.


I worked during the past month in the branch "shadowstack-perf-2".
This gives a major improvement on the placement of pushing and popping
GC roots on the shadow stack.  I think it's worth merging that branch
in any case.  On x86, it gives roughly 3-4% speed improvements; I'd
guess on arm it is slightly more.  (I'm comparing the performance
outside JITted machine code; the JITted machine code we produce is
more similar.)

The problem is that asmgcc used to be ~10% better.  IMHO, 3-4% is not
quite enough to be happy and kill asmgcc.  Improving beyond these 3-4%
seems to require some new ideas.


So I'm also thinking about ways to fix asmgcc more generally, this
time focusing on Linux only; asmgcc contains old code that tries to
parse MSVC output, and I bet we tried with clang at some point, but
these attempts both failed.  So let's focus on Linux and gcc only.

Asmgcc does two things with the parsed assembler: it computes the
stack size at every point, and it tracks some marked variables
backward until the previous "call" instruction.

I think we can assume that the version of gcc is not older than, say,
the one on tannit32 (Ubuntu 12.04), which is gcc 4.6.  At least from
that version, both on x86-32 and x86-64, gcc will emit "CFI
directives" (https://sourceware.org/binutils/docs/as/CFI-directives.html).
These are a saner way to get the information about the current stack
size.

About the backward tracking, we need to have a complete understanding
of all instructions, even if e.g. for any xmm instruction we just say
"can't handle GC pointers".  The backward tracking itself is often
foiled because the assembler is lacking a way to know clearly "this
call never returns" (e.g. calls to abort(), or to some RPython helper
that prints stuff and aborts).  In other words, the control flow is
sometimes hard to get correctly, because a "call" generally returns,
but not always.  Such mistakes can produce bogus results (including
"cannot find gc roots!").

What can we do about that?  Maybe we can compile with "-s
-fdump-final-insns".  This dumps a gcc-specific summary of the RTL,
which is the final intermediate representation, which looks like it is
in one-to-one correspondance with the actual assembly.  It would be a
better input for the backward-tracker, because we don't have to handle
tons of instructions with unknown effects, and because it contains
explicit points at which control flow cannot pass.  On the other hand,
we'd need to parse both the .s and this dump in parallel, matching
them as we go along.  But I still think it would be better than now.

Of course the best would be to get rid of asmgcc completely...

This mail is meant to be a dump of my current mind's state :-)


A bientôt,

Armin.
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev