llvm dev - Feb 2010 - [LLVMdev] Stuck

Hi Talin,

On Feb 27, 2010, at 22:06, Talin wrote:
> The main problem with shadow-stack is that it's not thread-safe.
It sounds like you've outgrown it, then.
> What about modifying the shadow-stack to use a thread-local linked list? 
> Another alternative is to add an additional parameter to every function
containing the address of the head of the stack frame list.

 and have a good understanding of why. Many managed runtimes tackle this
threadstate problem.
> The ideal solution would be to walk the stack directly, without needing an
auxiliary data structure. [...] which would likely be different on different
processors and maybe different OSs as well.
Yes, this requires platform-specific code. One of the unique design advantages
of the shadow stack is that it doesn't.
> Also, even if I had the address of the call frame, I don't know if the
table of offsets from the call frame to the stack roots would be reliable, since
I imagine things might shift around during code generation.
The stack root offsets are computed during code generation. You ought not be
concerned about it.
> The various _Unwind functions give me the IP and the function start, but
not the address of the call frame. There is an ability to get the value of any
arbitrary register, but I don't know which register contains what I would
need
Then you should look it up.
> Another problem with the _Unwind functions is that they aren't
supported on all platforms either. (This is a problem I will eventually have to
solve anyway, since my exception personality function also uses these
functions.)
In practice, so long as frame pointers are not elided, a handful of lines of
assembly per platform should get you a stack walker. If frame pointers are
elided, however, you're looking at parsing DWARF to find out where it was
saved, which is probably too expensive for the job.

— Gordon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100228/80610e7b/attachment.html>

On Sun, Feb 28, 2010 at 9:55 AM, Gordon Henriksen
<gordonhenriksen at me.com> wrote:
> In practice, so long as frame pointers are not elided, a handful of lines
of
> assembly per platform should get you a stack walker. If frame pointers are
> elided, however, you're looking at parsing DWARF to find out where it
was
> saved, which is probably too expensive for the job.
Unless you have control of all the binaries that you're interfacing
with, please don't assume that.  Since DWARF frame information was
made part of the AMD64 System V ABI, everyone has been taking the
opportunity to elide frame pointers.

Reid

On 2010-02-28, at 13:27, Reid Kleckner wrote:
> On Sun, Feb 28, 2010 at 9:55 AM, Gordon Henriksen
> <gordonhenriksen at me.com> wrote:
> 
>> In practice, so long as frame pointers are not elided, a handful of
lines of assembly per platform should get you a stack walker. If frame pointers
are elided, however, you're looking at parsing DWARF to find out where it
was saved, which is probably too expensive for the job.
> 
> Unless you have control of all the binaries that you're interfacing
with, please don't assume that.  Since DWARF frame information was made part
of the AMD64 System V ABI, everyone has been taking the opportunity to elide
frame pointers.
There's nothing wrong with Talin taking advantage of frame pointers in his
language's implementation.

Assuming them of foreign functions is of course problematic, but there's no
need to scan foreign stack frames. Tracking FFI entry/exits so that foreign
frames can be skipped solves that problem.

— Gordon