Re: stack-protector guard location

[Richard Henderson <rth at redhat dot com>]

On 08/27/2009 03:55 PM, Roland McGrath wrote:
> A developer had a stack-protector hit and wanted to debug it.  (Of
> course the first answer is usually valgrind.  But it so happened that
> valgrind didn't find that case, and moreover it just got me thinking
> about the feature taken on its own.)
>
> So it comes to, I know a callee is clobbering my frame, what do I do?
> You put a watchpoint on the frame's guard word address and continue.
> I put a watchpoint where?
> ...So I've read the disassembly with my little brain and computed it...thanks.
>
> I like the idea of the last step being automated.  i.e.
>
> (gdb) p&$guard
> $44 = (void *volatile *) 0x7fffffffdd90
> (gdb) watch *$44
>
> When it all fits together, also:
>
> 	probe function("*") { watch $guard }
> 	probe function("*").return { unwatch $guard }
> 	probe watch { println("clobbered!\n" + backtrace()) }
>
> or whatever.
>
> So how can you really find it at low level.  I guess it is always
> supposed to be the end of the frame (however findable that is).  But I
> found cfgexpand.c:create_stack_guard, which gives me the impression
> it's really just:
>
> 	void *volatile anonymous = magic;
>
> early in the function.  i.e., vanilla frame layout rules apply and it
> just winds up at the end of the frame because it's the first local defined?
>
> So without really understanding anything about the compilation, I am now
> assuming that in the general case the location is not fixed in a way
> that a debugger could ascertain generically for any given frame.
>
> So, how about that anonymous decl gets some DWARF?  i.e.
>
> <variable artificial=true type="#volatile_ptr_type" location="fbreg(-44)"/>
>
> preferably first thing in the<subprogram>  (or maybe after<formal_parameter>s).
>
> That is, location= being the good part, and type= pointing to the usual:
>
> volatile_ptr_type:	<volatile_type type="#ptr_type"/>
> ptr_type:		<pointer_type byte_size=8/>
>
> i.e. "void *volatile", but that's fully language-agnostic DWARF.
>
> This seems like it should be easy enough.  I'm assuming it's just some
> bits not filled in by create_stack_guard that prevent this decl from
> producing DWARF anyway.

The following patch names this variable __stack_guard__ and injects
it into the top-level scope of the function.

Comments on the name or anything?  Otherwise I'll commit this to
mainline and 4.4 branch in 48 hours or so.


r~

Attachment: d-guard-1
Description: Text document