Adding per-application configuration data
sphink at gmail.com
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 ocallahan.org>wrote:
> On Thu, Apr 10, 2014 at 7:08 PM, Chris Jones <jones.chris.g at gmail.com>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  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.
> 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 mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rr-dev