This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Only set the executable module for a target once
ClosedPublic

Authored by teemperor on May 28 2020, 7:33 AM.

Details

Summary

When we try to find the executable module for our target we don't check
if we already have an executable module set. This causes that when debugging
a program that dlopens another executable, LLDB will take that other executable
as the new executable of the target (which causes that future launches of the
target will launch the dlopen'd executable instead of the original executable).

This just adds a check that we only set the executable when we haven't already
found one.

Fixes rdar://63443099

Diff Detail

Event Timeline

teemperor created this revision.May 28 2020, 7:33 AM
jasonmolenda accepted this revision.May 28 2020, 2:19 PM

This looks good to me, thanks Raphael.

This revision is now accepted and ready to land.May 28 2020, 2:19 PM
jingham requested changes to this revision.May 28 2020, 2:58 PM
jingham added a subscriber: jingham.

I don't think that test is right. There's no guarantee that your GetExecutable().GetFilename() runs before or after the dlopen in the process has run. If it runs before you aren't testing anything.

Can you set a second breakpoint at the return i and do lldbutil.continue_to_breakpoint instead of just Continue?

This revision now requires changes to proceed.May 28 2020, 2:58 PM
teemperor updated this revision to Diff 267225.May 29 2020, 7:06 AM

@jingham Yeah that is a good point. Updated the test. Thanks!

jingham added inline comments.May 29 2020, 10:36 AM
lldb/test/API/functionalities/dlopen_other_executable/TestDlopenOtherExecutable.py
23

One little nit, breakpoint.IsValid doesn't actually check very much. You would have to miss-call a breakpoint API for it to return an invalid breakpoint. After all, breakpoints are search kernels, and IsValid just tells you whether you made a valid search kernel. What you really want to check here is whether your breakpoint got any locations. I think this mistake is made a bunch of times in the testsuite...

It's not terribly vital because if you didn't "continue_to_breakpoint" is going to return no stopped threads.

teemperor updated this revision to Diff 267599.Jun 1 2020, 6:18 AM
  • Fix breakpoint validation (thanks Jim!)
teemperor updated this revision to Diff 268783.Jun 5 2020, 7:01 AM
  • Disable the test on Linux as glibc's dlopen doesn't support opening executables.
teemperor accepted this revision.Jul 16 2020, 11:01 PM

@jingham I assume this just slipped out of your review queue because Jason already accepted it, so I'll go ahead and land this. I can fix any further issues post-commit (users are pinging me to land this).

This revision was not accepted when it landed; it landed in state Needs Review.Jul 16 2020, 11:36 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJul 16 2020, 11:36 PM