[Lldb-commits] [PATCH] D65282: ObjectFileELF: permit thread-local sections with overlapping file addresses
Pavel Labath via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Fri Jul 26 02:13:59 PDT 2019
labath marked an inline comment as done.
labath added a comment.
> Do you mind explaining more how you'd like to improve file-address-based lookups for PT_TLS?
I don't have this fully thought through (I was hoping this would develop as use cases start showing up), but...
Are you referring to the "image lookup" command specifically, or is it a more general question about the internals of lldb too?
Regarding "image lookup", the simplest way would be to add a "--tls" flag to look in the "tls" address space. Or even a more generic "address space" flag, as there are people interested in more address spaces. Or, we could just change the command to find and display multiple matches. But then the test here would need to be changed, as my main interest is that the correct address is found when evaluating DW_OP_addr and friends -- the "image lookup" thing is just a proxy.
As for internal interfaces, I guess similar options would be possible, but there I'm even more fuzzy about which ones are better because I don't know what are the ways in which this may be used. I know that the DW_OP_form_tls_address lookup currently completely ignores the "file" addresses of the sections and just straight to "load" addresses and real memory. This is not completely surprising as you need a thread to see thread local data, and if you have a thread, you have a live process to query. However, I can see how it might be interesting to be able to see the initial value of a thread local variable much like we can display the initial value of a global variable without launching a process. For this case, a flag to `Section::ContainsFileAddress` saying "yes, I want to look up in thread-local sections now" would suffice, but I don't know if this is the only use case...
Comment at: lit/Modules/ELF/PT_LOAD-overlap-PT_TLS.yaml:68
+ Flags: [ SHF_ALLOC, SHF_WRITE, SHF_TLS ]
+ Address: 0x1010
+ AddressAlign: 0x4
> > .tbss 0x1000 NOBITS
> > .tdata 0x1010 PROGBITS
> Move .tdata before .tbss (0xff0) to make the example more realistic?
> .tdata has a larger address than .tbss. I think this is impossible in ld.bfd, but you can make .tbss go before .tdata with a broken lld linker script.
I'll change the order here. The thing I was trying to test here is that addresses in .data are found regardless of whether it comes before or after a tls section. I think already having two TLS segments is somewhat unrealistic, and I could make it more real by splitting this into two tests, but it did not seem necessary, as lldb does not care about details like this.
CHANGES SINCE LAST ACTION
More information about the lldb-commits