================
@@ -1477,32 +1506,32 @@ size_t
ObjectFileELF::GetSectionHeaderInfo(SectionHeaderColl §ion_headers,
}
if (idx < section_headers.size())
section_headers.resize(idx);
+ // Sometimes we are able to read the section header memory from an in memory
----------------
clayborg wrote:
We actually want this to work for ELF files when we don't have the file and it
is only in memory. GPU debugging often has images that are in memory only and
we need those section headers. I agree with you that normal binaries loaded by
the dynamic loader have this issue, but if we have JIT solutions that produce
ELF files in memory, or GPU stuff that will compile things on the fly and point
debuggers to ELF files in memory, then we should allow for this somehow.
I guess we will need to modify the SBModule from memory API to take a size so
that it can be specified, though this can still be wrong for most linux
binaries. My example's section headers were in the dynamic section:
```
(lldb) image lookup --verbose --address 0x0000555555554000+0x0000000000003f88
Address: a.out[0x0000000000003f88] (a.out.PT_LOAD[3]..dynamic + 448)
Summary: a.out`_DYNAMIC + 448
Module: file = "/home/gclayton/local/args/a.out", arch = "x86_64"
Symbol: id = {0x00000033}, range =
[0x0000555555557dc8-0x0000555555557fd8), name="_DYNAMIC"
```
Let me know what you think of being able to specify the size of the ELF data in
memory as a fix? By default if anyone loads something from memory from say a
core file, they shouldn't specify the size of the range and we would avoid
reading the section headers. But if they do specify it, then we would try to
read them, but only if they are contained within the data buffer for the object
file? Ack, neither sounds great.
https://github.com/llvm/llvm-project/pull/129166
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
