Adding per-application configuration data

Steve Fink sphink at
Thu Apr 10 11:26:56 PDT 2014

>From poking at it a little bit, it looks like when gdb gets control after a
SEGV, we're not yet in AsmJSFaultHandler. It's still in the calling
function. Though if you step a single instruction, you're in the handler.

The malloc+sigaction dance is pretty nasty. Would doing a stepi in the
inferior, followed by checking $rip == AsmJSFaultHandler work, or does it
end up with the same issues? I don't understand the setup is, in terms of
what rr does and what gdb does.

On Thu, Apr 10, 2014 at 12:26 AM, Robert O'Callahan <robert at>wrote:

> On Thu, Apr 10, 2014 at 7:08 PM, Chris Jones <jones.chris.g at>wrote:
>> I'm a bit hesitant about going this route, especially if the use case so
>> far is continuing through AsmJSFaultHandler().  Are we sure that the
>> equivalent of [1] can't be done with gdb macros that don't require
>> executing code in the tracee?
>> My concern over the "application behaviors" is that rr will end up
>> duplicating gdb functionality.  For example, to implement
>> |AsmJSFaultHandler = continue|, rr needs to first look up debug info for
>> sighandler functions that are invoked during execution.  Theoretically, rr
>> can ask the gdb remote protocol for this.  If that doesn't work, or gdb
>> doesn't send back enough info, we're back to parsing DWARF.  Then, rr has
>> to know that the string "AsmJSFaultHandler" should match whatever debuginfo
>> gdb sends us (or rr resolves itself), preferably using gdb's matching
>> heuristics.  "AsmJSFaultHandler" may resolve to more than one symbol with
>> different args and/or in different namespaces, .
> Certainly doable, but my personal preference would be to try to fix the
>> existing gdb helper before building this new mechanism into rr.
> Fair enough.
> Perhaps the gdb commands can be modified so on SEGV we just check if we're
> at AsmJSFaultHandler and if so, continue. I don't know why it's written to
> call sigaction the way it is.
> Rob
> --
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
> le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
> stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
> 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
> waanndt  wyeonut  thoo mken.o w
> _______________________________________________
> rr-dev mailing list
> rr-dev at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the rr-dev mailing list