https://github.com/dlav-sc closed
https://github.com/llvm/llvm-project/pull/99045
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
dlav-sc wrote:
> I put up a PR that avoids a memory region starting at address 0, and also
> clarifies the documentation of the qMemoryRegionInfo packet to state that
> permissions: are required for all memory regions that are accessible by the
> inferior process. A memory region with no `perm
jasonmolenda wrote:
I've merged https://github.com/llvm/llvm-project/pull/100288 I think we should
close this PR.
https://github.com/llvm/llvm-project/pull/99045
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
jasonmolenda wrote:
I put up a PR that avoids a memory region starting at address 0, and also
clarifies the documentation of the qMemoryRegionInfo packet to state that
permissions: are required for all memory regions that are accessible by the
inferior process. A memory region with no `permis
jasonmolenda wrote:
Ah, but I see my misunderstanding as I look at what debugserver returns. It
uses "no permissions" to indicate a memory range that is unmapped --
```
< 23> send packet: $qMemoryRegionInfo:0#44
< 27> read packet: $start:0;size:1;#00
< 31> send packet: $qMemoryR
jasonmolenda wrote:
I haven't tested it (or even tried to compile it, lol) but I think this loop
might be expressable as simply
```
MemoryRegionInfo region_info;
while (process_sp->GetMemoryRegionInfo(ret, region_info) == err.Success() &&
region_info.GetRange().GetRangeEnd() - 1
jasonmolenda wrote:
I think we should change these checks to look for an explicitly inaccessible
memory region, like
```
if (region_info.GetReadable() != MemoryRegionInfo::OptionalBool::eNo &&
region_info.GetWritable() != MemoryRegionInfo::OptionalBool::eNo &&
re
jasonmolenda wrote:
I'd describe this patch as handling the case where a remote stub cannot jit
memory and has a qMemoryRegion info packet which does not specify permissions.
The patch you reference makes jitted code expressions work, but I think
IRMemoryMap::FindSpec only needs to find space
dlav-sc wrote:
I connect to a riscv (rv64gv) machine, nothing special.
Lldb can just allocate memory on remote target only if the target supports
executing JIT-compiled code (`if (process_is_alive && process_sp->CanJIT())` on
the line `68`), otherwise lldb falls through and starts finding sui
jasonmolenda wrote:
To make sure I'm clear: I don't have a problem with the basic idea of the
change, although we could comment what is going on more clearly, and I'm
curious about that qMemoryRegionInfo packet. But it looks like you're
connecting to a device which can't allocate memory throu
jasonmolenda wrote:
I don't think this change is correct, or I don't understand what it is trying
to do.
When we're connected to a stub that can allocate memory in the target, none of
this code is executed. So lldb-server/debugserver will not hit this.
We send `qMemoryRegionInfo` packets to
DavidSpickett wrote:
Is this something specific to risc-v or simply uncovered by testing against a
certain risc-v target? Just wondering why we haven't had to do this before now.
https://github.com/llvm/llvm-project/pull/99045
___
lldb-commits mailing
12 matches
Mail list logo
