[Lldb-commits] [PATCH] fix debugging on linux

dawn at burble.org dawn at burble.org
Mon Nov 28 19:49:23 PST 2011 

Glad to see there's finally a buildbot for Linux - thank you!
I have 32-bit Linux - any way to get a buildbot set up for that?
I get much farther, so I suspect this is a problem with the 64-bit
Linux.

-Dawn

On Mon, Nov 28, 2011 at 09:33:09AM +0100, Duncan Sands wrote:
> The linux lldb buildbot http://lab.llvm.org:8011/builders/lldb-x86_64-linux
> is still failing, now with:
> 
> Collected 442 tests
> 
>    1: test_with_dsym (TestLogging.LogTestCase) ... skipped 'requires Darwin'
>    2: test_with_dwarf (TestLogging.LogTestCase) ... FAIL
>    3: test_with_dsym (TestFormatters.ExprFormattersTestCase)
>       Test expr + formatters for good interoperability. ... skipped 'requires 
> Darwin'
>    4: test_with_dwarf_ (TestFormatters.ExprFormattersTestCase)
>       Test expr + formatters for good interoperability. ... ERROR
>    5: test_expr_commands (TestPrintfAfterUp.Radar9531204TestCase)
>       The evaluating printf(...) after break stop and then up a stack frame. ... 
> python: LinuxThread.cpp:239: void LinuxThread::BreakNotify(const 
> ProcessMessage&): Assertion `bp_site' failed.
> make: *** [check-local] Aborted
> program finished with exit code 2
> 
> Ciao, Duncan.
> 
> On 28/11/11 03:03, Greg Clayton wrote:
> >
> > On Nov 23, 2011, at 11:31 PM, dawn at burble.org wrote:
> >
> >> This patch was created using clang/llvm rev 144569, lldb rev 144919 but has
> >> been updated to clang/llvm rev 144982, lldb rev 145118.  It gets debugging on
> >> Linux back to the state it was in in llvm/clang rev 143631, lldb rev 143774.
> >>
> >> Debugging on Linux broke when the assumption was made that a process could be
> >> launched by spawning it in a suspended state and then attaching to it.  That
> >> support does not exist on Linux.  To work around this, I added a new method
> >> "CanLaunchViaAttach" which tests whether the platform supports being launched
> >> in this way.  I wanted to add a flag to ProcessLaunchInfo, but could not find
> >> an easy way to set it from within the Linux plugins.
> >>
> >> Commit message:
> >>
> >> Fix debugging on Linux.
> >> Implement remote vs. host platform code as was done with PlatformDarwin.
> >> Platform::CanLaunchViaAttach(): new: return true if the process can be launched
> >>         via spawn and attach.  Default is true.  Override in PlatformLinux to false.
> >> Platform::DebugProcess(): if (!target->GetPlatform()->CanLaunchViaAttach())
> >>         then launch the process via CreateProcess and Launch.
> >>
> >> Please review and commit if acceptable.
> >
> > I checked in an alternate fix:
> >
> > % svn commit
> > Sending        include/lldb/Core/Module.h
> > Sending        include/lldb/Symbol/SymbolFile.h
> > Sending        include/lldb/Target/Platform.h
> > Sending        source/Commands/CommandObjectProcess.cpp
> > Sending        source/Core/Module.cpp
> > Sending        source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
> > Sending        source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
> > Sending        source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.h
> > Sending        source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
> > Sending        source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
> > Sending        source/Symbol/SymbolFile.cpp
> > Transmitting file data ...........
> > Committed revision 145219.
> >
> > % svn commit
> > Sending        Platform/Linux/PlatformLinux.h
> > Transmitting file data .
> > Committed revision 145221.
> >
> >
> > The first one contains the necessary changes to CommandObjectProcess.cpp and to include/lldb/Target/Platform.h that allow a platform to say:
> >
> >
> >           virtual bool
> >           CanDebugProcess ()
> >           {
> >               return true;
> >           }
> >
> > This keeps the code out of the platform since when a platform launches a process, it shouldn't be tied to a process plug-in as in the patch you submitted.
> >
> > Here is the vision of platforms:
> >
> > - They should be able to list all of the processes on the platform. This way you can connect to your local machine and list the processes, or connect to a remote platform, and if the remote platform supports it, it can list the processes that are there.
> > - Platforms should support launching processes. Not always for debugging, but sometimes just to spawn a child process. On the localhost, this means just using the Host::LaunchProcess() functionality. This way, we just need to implement a single copy of the process launching code. When you create a remote platform, you should be able to link against the native linux or darwin launching code and then we don't end up with multiple copies of the launching code like we have now. You make a good point in that not all platforms will be able to support launching with a program stopped for debugging, so we now ask the platform up in the CommandObjectProcessLaunch class before we launch the process. This keeps the platform clean, yet also lets us fall back to just launching the process through the built in process plug-in.
> > - Platforms should support attaching to a remote process. Combined with being able to launch for debug, this allows debugging as we have it on MacOSX. If we do this while remotely connected to a remote darwin machine, we now have the ability to talk to a remote computer and launch, attach, list and do a lot more
> > - Platforms should know if there are files locally on the current machine in an SDK or PDK or some over developer kit/cross compiling sysroot, etc to allow locating files in terms of the path you would us on the remote machine. For example when debugging on a remote device, if the are asked to find the file for "/bin/ls", this might locally be located in developer kit directory such as
> > "/path/to/old/linux/sysroot/bin/ls". This allows you to debug remote machines, or event mount the root file system on a mountpoint so you have access to the files so you can debug.
> > - Platforms should be able to upload/download files so you could install a new binary and run it, or upload a shared library so we can locally cache it for faster debugging.
> >
> > We are in the process of slowly makine these Platforms a reality, so keep the questions coming if anyone has any.
> >
> > So in short: I made the fix you requested, but in a different way. If you can rework your patch around what is in top of tree, then we can get the rest of it submitted.
> >
> > Greg Clayton
> >
> >> Thanks!
> >> -Dawn
> >> <llvmR144982_lldbR145118.patch>_______________________________________________
> >> lldb-commits mailing list
> >> lldb-commits at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
> >
> > _______________________________________________
> > lldb-commits mailing list
> > lldb-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
> 
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits

More information about the lldb-commits mailing list