I committed your patch in r181722. Thanks again! Some other comments inline...
On 2013-05-13, at 12:43 PM, Greg Clayton <[email protected]> wrote: > > On May 10, 2013, at 5:30 PM, Mike Sartain <[email protected]> wrote: > >> On Fri, May 10, 2013 at 1:41 PM, Kopec, Matt <[email protected]> wrote: >> >>> Thanks for contributing the patch! This will help many of us in debugging >>> lldb. Good to know there are other Linux lldb developers out there. :) >> >> Thanks Matt. We're doing a lot of debugging on Linux and I'm hoping to do >> whatever I can to make lldb a much better debugger than gdb / cgdb - what >> most of use are currently using. > > We look forward to getting more people working on LLDB in general, I am glad > to see more people getting on board! > > >> I'm just now starting to get in the code and poke around and see what's >> there. If you have any suggestions on where I could help and not duplicate >> work, please fire away. > > The libedit code in the "lldb" binary seems to be a bit flaky on linux. > Sometimes the (lldb) prompt does't show up and other times the newlines after > entered commands come out in the command output. Anything that can be done to > solidify the libedit based code on linux would be a great help. > The libedit issue would be a good start. Also, here is the lldb bugzilla tracker: http://llvm.org/bugs/buglist.cgi?product=lldb&component=All%20Bugs&resolution=--- The libedit issue is here: http://llvm.org/bugs/show_bug.cgi?id=14637 Presently, we are working towards fixing multi-threaded debugging on Linux. We've made some progress (can view inferior threads, stop all inferior threads on a breakpoint hit). We also run into higher priority issues from time to time (build breakage, regressions, etc.) that we try to resolve asap. >> >>> Some comments about the patch... >>> >>>> +#elif defined (__linux__) >>>> + void *fn = dlsym (RTLD_DEFAULT, "pthread_setname_np"); >>>> + if (fn) >>>> + { >>> >>> I believe this pthread function can be added by including pthread.h for >>> Linux. That way you don't need dlsym and can just re-use most of the code >>> that is already there for apple. >> >> pthread_setname_np was added in glibc v2.12, so anything running less than >> that would run into issues if we called it directly. As an example on the >> Ubuntu side, I believe 10.04 LTS shipped with 2.11.1. What are your thoughts >> / requirements for minspecs like this? > > > dlsym() is the right way to go to avoid build issues and distribution issues. > We will need to keep this in for at least a few years until we require at > least a certain version of glibc on linux. > >> >>>> + const char *lastdot = ::strrchr( thread_name, '.' ); >>>> + >>>> + if (lastdot && lastdot != thread_name) >>>> + thread_name = lastdot + 1; >>>> + ::strncpy (namebuf, thread_name, sizeof(namebuf)); >>>> + namebuf[ sizeof(namebuf) - 1 ] = 0; >>>> + >>>> + int namebuflen = strlen(namebuf); >>> >>> It would have been nice to use std::string and its' facilities. It would >>> make this easier to write and understand but what you have is fine. >> >> I'll switch this over to using std::string on Monday and resubmit. Would >> have done it today but I just got back from a Pioneer Farms fieldtrip. Whee! >> :) >> >> Thanks for the reply. Have a great weekend. >> -Mike >> >> _______________________________________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
