Current quality/support of lldb on 32-bit Linux systems

Subprojects LLDB
#1

Hi

Could somebody please make a statement on the current quality of building lldb on 32-bit linux systems, and then using the lldb built to debug 32-bit linux processes?

I'm currently using a virtual box guest with access to only 2.3GB of the hosts RAM and really struggling. I have managed to build (with gcc-4.8.2) lldb without debug symbols, but any attempt to build with debugging just results in the kernel (I think) killing the ld invocation.

When I do manage to build an lldb, I'm finding that the debug experience is a bit shaky, e.g. the register reading layer seems to be inaccurate, and the inferior process status is often misreported.

I am happy to contribute somewhat in this area (I have some wait/ptrace etc. experience) - but I wondered whether my continued exploits into 32bit-linux were actually worthwhile...

Any advice appreciated,
Matthew Gardiner

Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.

#2

Hi Matthew,

I am working on Linux lldb, but currently I am focused on the x86_64 build, specifically on Ubuntu LTS systems (so 12.04 right now, until we bump up to the next one).

My only experience with the 32-bit version on Ubuntu 12.04 x86 was that I could not build it using a configure/(g)make Debug+Asserts build as the compiler/linker would run out of memory. I did get it to make it past several OOM situations, but could never get past liblldb.so linkage using gcc 4.8.2 on a debug build. When I switched to a release build (optimizations enabled, no debug info in the lldb build), then I could make it through the build process.

As to the quality question as it pertains to Linux x86_64 (and probably Linux as a whole): I have run into several what I’d call significant bugs where I could not debug development work without first fixing a bug in lldb. The good news is that these bugs are getting fixed now as my team hits them.

On a related note: in an effort to increase confidence in the state of the code, we are in the process of gathering some code coverage information for lldb under Linux x86_64 when running the local tests. This would be a first approximation as to how much work we may need to do to ensure we’ve got lldb Linux running reasonably reliably. I’ll make an attempt to characterize those results once I have them. (Right now the gcov/lcov-built lldb is crashing when run, so I need to track that down first). It is likely that x86 Linux will share similar results as the x86_64 side w/r/t reliability.

I hope that helps, Matthew.

Sincerely,
Todd Fiala

#3

Todd Fiala wrote:

Hi Matthew,

I am working on Linux lldb, but currently I am focused on the x86_64 build, specifically on Ubuntu LTS systems (so 12.04 right now, until we bump up to the next one).

My only experience with the 32-bit version on Ubuntu 12.04 x86 was that I could *not* build it using a configure/(g)make Debug+Asserts build as the compiler/linker would run out of memory. I did get it to make it past several OOM situations, but could never get past liblldb.so linkage using gcc 4.8.2 on a debug build. When I switched to a release build (optimizations enabled, no debug info in the lldb build), then I could make it through the build process.

Yes, as I'd imagined - Linux 32-bit is currently seeing little action.

As to the quality question as it pertains to Linux x86_64 (and probably Linux as a whole): I have run into several what I'd call significant bugs where I could not debug development work without first fixing a bug in lldb. The good news is that these bugs are getting fixed now as my team hits them.

On a related note: in an effort to increase confidence in the state of the code, we are in the process of gathering some code coverage information for lldb under Linux x86_64 when running the local tests. This would be a first approximation as to how much work we may need to do to ensure we've got lldb Linux running reasonably reliably. I'll make an attempt to characterize those results once I have them. (Right now the gcov/lcov-built lldb is crashing when run, so I need to track that down first). It is likely that x86 Linux will share similar results as the x86_64 side w/r/t reliability.

I hope that helps, Matthew.

Yes, thanks for this, Todd. Meanwhile I'm going to attempt to persuade my 32-bit build to work correctly. I think the main problem is that the register map is wrong, in fact I'm wondering if the 64-bit map is being used instead. I'm new to lldb, so I can't make any strong assumptions. Anyway, I'll keep digging.

Thanks again,
Matt

Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.

#4

Hi Todd,

I fixed one of the 32-bit linux problems I've been encountering. The problem (I think) is that the POSIXThread::GetRegisterContext() in POSIXThread.cpp was creating RegisterContextLinux_x86_64 regardless of the target_arch.GetCore().

I currently have no commit access so I'm publishing my diff, in case someone else in the mailing list (CCd) perhaps has the time to pursue this further.

[0][][m][] > svn diff lldb/source/Plugins/Process/POSIX/POSIXThread.cpp
Index: lldb/source/Plugins/Process/POSIX/POSIXThread.cpp