[Lldb-commits] [PATCH] Refactor POSIXThread::GetRegisterContext and use i386 register context

Todd Fiala tfiala at google.com
Thu Feb 13 10:37:10 PST 2014

  I tried this on Ubuntu 13.10 x86 using all stock components (gcc 4.8.1, libedit-dev) and this patch (with breaks fixed).  I build a Release and Asserts build using cmake/ninja.

  cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_CXX11=ON -DCMAKE_INSTALL_PREFIX:PATH=`pwd`/../install ../llvm

  I tried to debug a simple program:

    #include <stdio.h>

    int main(int argc, char **argv)
      printf("Hello, world! I found %d args on the command line\n", argc);
      for (int i = 0; i < argc; ++i)
          printf("arg %d: %s\n", i, argv[i]);

  (pardon the default editor indenting, not my normal setup...)

  Produces the following when run from the command line:

  tfiala at ubuntu:~/play/hello$ ./hello a b c
  Hello, world! I found 4 args on the command line
  arg 0: ./hello
  arg 1: a
  arg 2: b
  arg 3: c

  When I try to run it with the lldb that I built, here's what I see:

  tfiala at ubuntu:~/play/hello$ ~/lldb/work/build/bin/lldb hello
  Current executable set to 'hello' (i386).
  (lldb) run
  Process 12157 launching
  Segmentation fault (core dumped)

  Debugging the core with lldb doesn't work.  Invalid stack frames.

  gdb shows the following:

  tfiala at ubuntu:~/play/hello$ gdb ~/lldb/work/build/bin/lldb core
  GNU gdb (GDB) 7.6.1-ubuntu
  Copyright (C) 2013 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "i686-linux-gnu".
  For bug reporting instructions, please see:
  Reading symbols from /home/tfiala/lldb/work/build/bin/lldb-3.5...(no debugging symbols found)...done.

  warning: core file may not match specified executable file.
  [New LWP 12165]
  [New LWP 12172]
  [New LWP 12170]
  [New LWP 12174]
  [New LWP 12175]

  warning: Can't read pathname for load map: Input/output error.
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
  Core was generated by `/home/tfiala/lldb/work/build/bin/lldb hello'.
  Program terminated with signal 11, Segmentation fault.
  #0  0xb53f45b9 in POSIXThread::WatchNotify(ProcessMessage const&) () from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  (gdb) bt
  #0  0xb53f45b9 in POSIXThread::WatchNotify(ProcessMessage const&) () from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  #1  0xb53f1a02 in LinuxThread::TraceNotify(ProcessMessage const&) () from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  #2  0xb53f51af in POSIXThread::Notify(ProcessMessage const&) () from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  #3  0xb53f8fcd in ProcessPOSIX::RefreshStateAfterStop() () from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  #4  0xb5297da3 in lldb_private::Process::ShouldBroadcastEvent(lldb_private::Event*) ()
     from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  #5  0xb5298159 in lldb_private::Process::HandlePrivateEvent(std::shared_ptr<lldb_private::Event>&) ()
     from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  #6  0xb52a119e in lldb_private::Process::Launch(lldb_private::ProcessLaunchInfo&) ()
     from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  #7  0xb52c4d2a in lldb_private::Target::Launch(lldb_private::Listener&, lldb_private::ProcessLaunchInfo&) ()
     from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  #8  0xb544264b in CommandObjectProcessLaunch::DoExecute(lldb_private::Args&, lldb_private::CommandReturnObject&) ()
     from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  #9  0xb51f03d3 in lldb_private::CommandObjectParsed::Execute(char const*, lldb_private::CommandReturnObject&) ()
     from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  #10 0xb51ed1e6 in lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, lldb_private::ExecutionContext*, bool, bool) () from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  #11 0xb51ee77e in lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::string&) ()
     from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  #12 0xb5127966 in lldb_private::IOHandlerEditline::Run() () from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  #13 0xb510906f in lldb_private::Debugger::ExecuteIOHanders() () from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  #14 0xb51dfd78 in lldb_private::CommandInterpreter::RunCommandInterpreter(bool, bool) ()
     from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  #15 0xb50319cd in lldb::SBDebugger::RunCommandInterpreter(bool, bool) () from /home/tfiala/lldb/work/build/lib/liblldb.so.3.5
  #16 0x0804b5ee in Driver::MainLoop() ()
  #17 0x0804a546 in main ()
  (gdb) info locals
  No symbol table info available.

  So, something is definitely not right.  I'm not sure if it's related to this patch.  It's blowing up in WatchNotify().

  I'll see if I can get a debug build of lldb x86 working --- that's the scenario that hasn't been building for me in a VM (OOM), but that was with configure/(g)make.  I'll see if cmake/ninja can manage resources better in that case.

  Right now this patch isn't looking good for lldb Linux x86, but I don't know that it is making it worse.  More in a bit...


More information about the lldb-commits mailing list