Re: [lldb-dev] Access to TLS variables on GNU/Linux
* Jan Kratochvil:
> On Tue, 14 May 2019 13:38:57 +0200, Florian Weimer via lldb-dev wrote:
>> The target process has loaded libpthread.so.0, so it's not the usual
>> problem of libthread_db not working without libpthread.
>>
>> On the other hand, I realize now that the lldb command cannot access TLS
>> variables, either. Is this expected to work at all?
>
> TLS is implemented only for FreeBSD as there is
> FreeBSDThread::GetThreadPointer() but on Linux it falls back to unimplemented:
> lldb::addr_t Thread::GetThreadPointer() { return LLDB_INVALID_ADDRESS; }
>
> On Linux it uses DynamicLoaderPOSIXDYLD::GetThreadLocalData() which may work
> without libthread_db as it is reading "_thread_db_*" symbols in
> DYLDRendezvous::GetThreadInfo(). But it needs that GetThreadPointer() which
> could get implemented (for x86_64) by reading %fs_base. LLDB currently does
> not know anything about %fs_base+%gs_base.
>
If I can get the TLS base address on x86 for a thread and if LLDB can
expose the offset of an initial-exec TLS variable inside the TLS block
of an object (which should be encoded in the ELF data), I can poke at
glibc internals and figure out the offset from thread pointer.
(Global-dynamic TLS is much more difficult to handle, of course.)
> Is it a good idea to implement %fs_base+%gs_base to make TLS working
> on Linux?
The register access would help, I think. Even if the rest doesn't work.
If you have an experimental build, I can try it.
Thanks,
Florian
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Lldb-commits] [lldb] r360757 - Group forward declarations in one namespace lldb_private {}
On 16/05/2019 01:10, Jim Ingham via lldb-dev wrote: When you add to them you are often adding some larger feature which would have required a rebuild anyway, and they go long times with no change... I have never found the rebuild required when these files are touched to be a drag on my productivity. And I really appreciate their convenience. But thanks for your friendly advice. Jim I don't want to make a big deal out of it, but I'm also not a fan of the lldb-forward header. My two main reasons are: - it's inconsistent with the rest of llvm, which does not have any headers of such sort (LLVM.h, which we talked about last time, is the only thing remotely similar, but that's still has a much more narrow scope) - it makes it easier to violate layering. Eg. right now I can type something like: void do_stuff_with(Target *); in to a "Utility" header, and it will compile just fine because it will have the forward-declaration of the Target class available even though nothing in Utility should know about that class. Neither of these is a big problem: this is not the most important thing we differ from llvm, and also the layering violation will become obvious once you start to implement the "do_stuff_with" function (because you will hopefully need to include the right header to get the full definition). However, for these reasons, I would prefer if we got rid of this header, or at least moved towards a world where we have one forward-declaring header for each top-level module (so "lldb/Utility/forward.h", would forward-declare only Utility stuff, etc.). pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 41885] Variable with end part that is optimized out is printed incorrectly
https://bugs.llvm.org/show_bug.cgi?id=41885 Paul Robinson changed: What|Removed |Added Assignee|unassignedb...@nondot.org |lldb-dev@lists.llvm.org Product|libraries |lldb Version|trunk |unspecified Component|DebugInfo |All Bugs --- Comment #2 from Paul Robinson --- Move to LLDB. If the LLDB folks think I'm crazy they can move it back. -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Lldb-commits] [lldb] r360757 - Group forward declarations in one namespace lldb_private {}
> On May 16, 2019, at 2:24 AM, Pavel Labath wrote: > > On 16/05/2019 01:10, Jim Ingham via lldb-dev wrote: >> When you add to them you are often adding some larger feature which would >> have required a rebuild anyway, and they go long times with no change... I >> have never found the rebuild required when these files are touched to be a >> drag on my productivity. And I really appreciate their convenience. >> But thanks for your friendly advice. >> Jim > > I don't want to make a big deal out of it, but I'm also not a fan of the > lldb-forward header. My two main reasons are: > - it's inconsistent with the rest of llvm, which does not have any headers of > such sort (LLVM.h, which we talked about last time, is the only thing > remotely similar, but that's still has a much more narrow scope) > - it makes it easier to violate layering. Eg. right now I can type something > like: > void do_stuff_with(Target *); > in to a "Utility" header, and it will compile just fine because it will have > the forward-declaration of the Target class available even though nothing in > Utility should know about that class. > > Neither of these is a big problem: this is not the most important thing we > differ from llvm, and also the layering violation will become obvious once > you start to implement the "do_stuff_with" function (because you will > hopefully need to include the right header to get the full definition). For sure, lldb-forward.h should only have forward declarations (or SP declarations) - as is the case now. So you can't do anything but pass an object along with only lldb-forward. I like it because it encourages not including the actual definition header files in other header files that don't need to see implementations. It provides the set of names you can refer to that lldb provides, so it is easy to make your interface declarations work w/o being tempted to grab too much. The dictate of living off lldb-forward.h actually helps to remove unnecessary dependencies. The common defines have the other benefit that if you know you should be including these you will more easily learn to look there and see LLDB_INVALID_ADDRESS rather than inventing your own local invalid address marker... > However, for these reasons, I would prefer if we got rid of this header, or > at least moved towards a world where we have one forward-declaring header for > each top-level module (so "lldb/Utility/forward.h", would forward-declare > only Utility stuff, etc.). > I'm not opposed to the latter option, though I'm not convinced it would be worth the churn. Jim > pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
