MaskRay added a comment.
> Are you referring to the "image lookup" command specifically, or is it a more
> general question about the internals of lldb too?
Both:) This patch doesn't change the `Address: a.o[0x00001010]
(a.o.PT_LOAD[0]..tdata + 0)` output so I was puzzled what this patch intends to
do.
> 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...
Yes, inspecting the initial value of a thread-local variable is a use case. To
that end, can this be done by introducing another member variable instead of
overloading `m_sections_up` with a new purpose (adding `PT_TLS`)? If PT_TLS is
recorded in a different variable, the change below can be deleted.
bool Section::ContainsFileAddress(addr_t vm_addr) const {
const addr_t file_addr = GetFileAddress();
- if (file_addr != LLDB_INVALID_ADDRESS) {
+ if (file_addr != LLDB_INVALID_ADDRESS && !IsThreadSpecific()) {
(An adjacent pair of PT_LOAD segments can load the same file contents, e.g.
PT_LOAD `[0x150, 0x1234)` and `[0x1234, 0x1800)` will transform to mmap calls
with ranges `[0, 0x2000)` and `[0x1000, 0x2000)` at runtime if the runtime page
size = 0x1000. They share one page in the file. If you ask what a specific
offset in the file is mapped to, there can be multiple PT_LOAD segments
(physical -> VMA is not unique). Fortunately the reverse mapping VMA ->
physical offset can be treated as unique in practice
(`[p_vaddr,p_vaddr+p_memsz)` ranges do not overlap).)
================
Comment at: lit/Modules/ELF/PT_LOAD-overlap-PT_TLS.yaml:68
+ Flags: [ SHF_ALLOC, SHF_WRITE, SHF_TLS ]
+ Address: 0x1010
+ AddressAlign: 0x4
----------------
labath wrote:
> MaskRay wrote:
> > > .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.
Multiple PT_TLS is unrealistic. None of glibc/musl/FreeBSD rtld supports more
than 1 PT_TLS (they will just pick the last one and ignore the others).
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D65282/new/
https://reviews.llvm.org/D65282
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
