This is an archive of the discontinued LLVM Phabricator instance.

[debugserver] Add option to propagate SIGSEGV to target process
ClosedPublic

Authored by aarzilli on Oct 13 2020, 6:41 AM.

Details

Summary

Adds a command line option that makes debugserver propagate the SIGSEGV signal to the target process.

Motivation: I'm one of the maintainers of Delve [1] a debugger for Go. We
use debugserver as our backend on macOS and one of the most often reported
bugs is that, on macOS, we don't propagate SIGSEGV back to the target
process [2]. Sometimes some programs will actually cause a SIGSEGV, by
design, and then handle it. Those programs can not be debugged at all.

Since catching signals isn't very important for a Go debugger I'd much
rather have a command line option in debugserver that causes it to let
SIGSEGV go directly to the target process.

[1] https://github.com/go-delve/delve/
[2] https://github.com/go-delve/delve/issues/852

Diff Detail

Event Timeline

aarzilli created this revision.Oct 13 2020, 6:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 13 2020, 6:41 AM
aarzilli requested review of this revision.Oct 13 2020, 6:41 AM

The return from a SIGSEGV or SIGILL has less information than the equivalent exception, so reporting the exceptions should be the default, but having a switch for people who need the exception to propagate is okay.

I wonder if the implementation would be less intrusive (and keep some of these functions from adding to their already too many arguments) if you added this flag to the RNBContext that RNBRemote holds onto. You'll still have to pass it down to the Mach layers by hand, but maybe you could do less work handing it from call to call. RNBContext has other related flags, so this seems a natural extension.

You might even get away with treating this as a launch flavor (which it sort of is), though to do that you'd have to make the launch flavor OR-able which might be more work than its worth.

aarzilli updated this revision to Diff 298077.Oct 14 2020, 2:14 AM

I wonder if the implementation would be less intrusive (and keep some of these functions from adding to their already too many arguments) if you added this flag to the RNBContext that RNBRemote holds onto.

Done.

You might even get away with treating this as a launch flavor (which it sort of is), though to do that you'd have to make the launch flavor OR-able which might be more work than its worth.

I'm not familiar enough with the codebase to do this.

Thanks, that's a little better.

It would be even nicer if the DNB API's you are adding "unmask_signals" to would take the Context instead. At this point they are pulling the launch flavor and the unmask signals from the context, so just getting the RNBContext would be cleaner. If you feel motivated to make that change as well, that would be great. But this is also okay as it stands.

aarzilli updated this revision to Diff 298319.Oct 15 2020, 12:32 AM

Like this?

jingham accepted this revision.Oct 15 2020, 9:54 AM

That's nicer, thanks!

This revision is now accepted and ready to land.Oct 15 2020, 9:54 AM

I don't want to be overbearing but should I be doing something else? Is this going to be merged and, if it is, what timeline should I expect?

I don't want to be overbearing but should I be doing something else? Is this going to be merged and, if it is, what timeline should I expect?

I think nobody realized you didn't have commit access, feel free to ask someone to merge something for you in the future. I'll take care of this patch for you.

I don't want to be overbearing but should I be doing something else? Is this going to be merged and, if it is, what timeline should I expect?

I think nobody realized you didn't have commit access, feel free to ask someone to merge something for you in the future. I'll take care of this patch for you.

Thank you.