[lldb-dev] Hang during attach

2016-01-08 Thread David Jones via lldb-dev
I have some code which worked under LLVM+LLDB 3.6.0 which runs as follows:
its purpose is to run some code, and print a backtrace if the code
segfaults. My approach was:
- fork
- the child runs the main part of the program.
- the parent creates a debugger and attaches to the child. The child is
continued and allowed to run until either it terminates or faults.

This code worked in 3.6.0:

switch (pid = fork()) {
case -1:
return; // no trace

case 0:
// child
fprintf(stderr, "child 1\n");
//pause();
fprintf(stderr, "child 2\n");
signal(SIGUSR1, SIG_DFL);
fprintf(stderr, "child 3\n");
return;

default:
// parent: create debugger
{
StateType   state;
//SBAttachInfoai(pid);

SBDebugger::Initialize();
m_Debugger = SBDebugger::Create(false);
if (!m_Debugger.IsValid())
fprintf (stderr, "error: failed to create a debugger
object\n");
m_Debugger.SetAsync(false);
m_Listener = m_Debugger.GetListener();
m_Target = m_Debugger.CreateTarget(exec_name);
fprintf(stderr, "parent 1\n");
//m_Target.Attach(ai, m_Error);
m_Target.AttachToProcessWithID(m_Listener, pid, m_Error);
fprintf(stderr, "parent 2\n");


Under LLVM+LLDB 3.7.1, I see the following instead:
- the child runs to completion (child 1/2/3 messages print out).
- the parent hangs in attach (parent 1 prints out but parent 2 does not)

Debugging the whole thing under GDB (unsure how reliable this is, but the
hang happens w/o GDB as well) shows:

child 1
child 2
child 3
[ child prints out other stuff and runs happily ]
parent 1
[ child terminates ]
[New Thread 0x7fffed043700 (LWP 470)]
[New Thread 0x7fffec842700 (LWP 472)]
[Thread 0x7fffec842700 (LWP 472) exited]
^C
Program received signal SIGINT, Interrupt.
0x72bd566b in pthread_join (threadid=140737169864448,
thread_return=0x0)
at pthread_join.c:92
92  pthread_join.c: No such file or directory.
(gdb) bt
#0  0x72bd566b in pthread_join (threadid=140737169864448,
thread_return=0x0) at pthread_join.c:92
#1  0x75f8247c in lldb_private::HostThreadPosix::Join(void**) ()
   from /tools/llvm/3.7.1dbg/lib/liblldb.so
#2  0x75f7034d in lldb_private::HostThread::Join(void**) ()
   from /tools/llvm/3.7.1dbg/lib/liblldb.so
#3  0x7610802e in
lldb_private::process_gdb_remote::GDBRemoteCommunication::StartDebugserverProcess(char
const*, unsigned short, lldb_private::ProcessLaunchInfo&, unsigned short&)
() from /tools/llvm/3.7.1dbg/lib/liblldb.so
#4  0x7612f5c0 in
lldb_private::process_gdb_remote::ProcessGDBRemote::LaunchAndConnectToDebugserver(lldb_private::ProcessInfo
const&) ()
   from /tools/llvm/3.7.1dbg/lib/liblldb.so
#5  0x7612fbde in
lldb_private::process_gdb_remote::ProcessGDBRemote::DoAttachToProcessWithID(unsigned
long, lldb_private::ProcessAttachInfo const&) ()
   from /tools/llvm/3.7.1dbg/lib/liblldb.so
#6  0x7623efa5 in
lldb_private::Process::Attach(lldb_private::ProcessAttachInfo&) () from
/tools/llvm/3.7.1dbg/lib/liblldb.so
#7  0x77025cc4 in
PlatformPOSIX::Attach(lldb_private::ProcessAttachInfo&,
lldb_private::Debugger&, lldb_private::Target*, lldb_private::Error&) ()
   from /tools/llvm/3.7.1dbg/lib/liblldb.so
#8  0x7626ef52 in
lldb_private::Target::Attach(lldb_private::ProcessAttachInfo&,
lldb_private::Stream*) () from /tools/llvm/3.7.1dbg/lib/liblldb.so
#9  0x75d4a4d7 in (anonymous
namespace)::AttachToProcess(lldb_private::ProcessAttachInfo&,
lldb_private::Target&) ()
   from /tools/llvm/3.7.1dbg/lib/liblldb.so
#10 0x75d4a149 in lldb::SBTarget::Attach(lldb::SBAttachInfo&,
lldb::SBError&) () from /tools/llvm/3.7.1dbg/lib/liblldb.so

Target is Ubuntu LTS 14.04 on x86_64.

Has anything changed in the API over the past year? It looks like LLDB is
creating a server internally; it is terminating quickly for some reason,
and the LLDB parent is waiting forever for its server.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


[lldb-dev] Canonicalize armv6l and armv7l to v6 and v7

2016-01-08 Thread William Dillon via lldb-dev
Hi all,

I have a small patch that fixes an issue that prevents use of the Swift REPL on 
arm-linux.  When working with targets that the OS presents as armv7l, for 
example, there is an inconsistency when the architecture sub-type is parsed.  
Detecting this condition and removing the ‘l’ fixes it.  I’ve tried to make 
this logic as restrictive in scope and application as possible.  It will only 
trigger on arm hosts in linux.

The theory of operation is that, within llvm, the v6l and v7l subtypes alias to 
v6 and v7 respectively.  Also in llvm, when a triple is created, the original 
string is preserved until parts of it are mutated.  When llvm executes its 
architecture synonym logic, armv7l (and armv6l once my patch there is merged) 
is resolved to armv7.  By querying the parsed subtype from llvm, this 
centralized logic is used to sanitize the architecture.  The end result is that 
if the architecture provided to the triple constructor is an alias for the v7 
or v6 subtype, it is discarded and replaced with v6 or v7 itself.

My hope is that this code can make it into the Swift 2.2 release, and I’m 
working with Bob Wison on a related patch to LLVM.  I appreciate any and all 
comments and suggestions.

Thanks!!
- Will



lldb.diff
Description: Binary data
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev