| Issue |
179913
|
| Summary |
LLDB errors when WAMR returns an empty memory range for addresses outside the valid address range
|
| Labels |
bug,
lldb
|
| Assignees |
|
| Reporter |
DavidSpickett
|
I'm trying out LLDB following https://jonasdevlieghere.com/post/wasm-debugging-with-lldb-and-wamr/.
`memory region` is for some reason my favourite command, so I tried that. Works for a value in the valid address range:
```
(lldb) memory region 0
lldb < 23> send packet: $qMemoryRegionInfo:0#44
lldb < 56> read packet: $start:0;size:10800;permissions:rw;name:6d656d6f7279;#40
[0x0000000000000000-0x0000000000010800) rw- memory
```
If you repeat the command, it will ask for the range at `0x10800`, and we get an unexpected response:
```
(lldb)
lldb < 27> send packet: $qMemoryRegionInfo:10800#0d
lldb < 53> read packet: $start:c000000000000000;size:0;permissions:;name:;#7d
error: Server returned invalid range
```
`--all` shows this all in one go:
```
(lldb) memory region --all
lldb < 23> send packet: $qMemoryRegionInfo:0#44
lldb < 56> read packet: $start:0;size:10800;permissions:rw;name:6d656d6f7279;#40
lldb < 27> send packet: $qMemoryRegionInfo:10800#0d
lldb < 53> read packet: $start:c000000000000000;size:0;permissions:;name:;#7d
error: Server returned invalid range
```
`qMemoryRegionInfo` is specific to LLDB and documented in https://lldb.llvm.org/resources/lldbgdbremote.html#qmemoryregioninfo-addr.
> If the address requested is not in a mapped region (e.g. we’ve jumped through a NULL pointer and are at 0x0) currently lldb expects to get back the size of the unmapped region – that is, the distance to the next valid region.
We got:
```
$start:c000000000000000;size:0;permissions:;name:;
```
* The start address is not the one we asked for. It is instead the value WAMR uses to represent an invalid address.
* The size is 0, this is probably rejected by packet parsing.
* Even if it wasn't, the `--all` algorithm would spin forever asking for `0xc000....` over and over.
* It should not have a `permissions:` key, though the impact of that is negligible. The user cannot tell from the output whether it has no permissions because it's unmapped, or because we don't know specifically what permissions it has. So this part doesn't fit the letter of the spec but in reality it's fine.
We have not defined what happens if you ask for an address outside of the range that is possible to be mapped.
Possible precedent is AArch64 with Top Byte Ignore. Where the virtual address is actually only 48-bits.
```
(lldb) process status -v
<...>
Addressable code address mask: 0xff7f000000000000
Addressable data address mask: 0xff7f000000000000
Number of bits used in addressing (code): 49
```
Mappable memory stops at 0x0001000000000000.
```
(lldb) memory region --all
[0x0000000000000000-0x0000aaaaaaaa0000) ---
<...>
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
```
Requesting `0x0001000000000000` is surprising because the address gets its non-address bits removed and becomes 0. This is correct, though strange to see:
```
(lldb) memory region 0x0001000000000000
lldb < 23> send packet: $qMemoryRegionInfo:0#44
lldb < 30> read packet: $start:0;size:aaaaaaaa0000;#cb
[0x0000000000000000-0x0000aaaaaaaa0000) ---
```
As you can see, it's the same as address 0:
```
(lldb) memory region 0
lldb < 23> send packet: $qMemoryRegionInfo:0#44
lldb < 30> read packet: $start:0;size:aaaaaaaa0000;#cb
[0x0000000000000000-0x0000aaaaaaaa0000) ---
```
I cannot request all the Fs at all:
```
(lldb) memory region 0xffffffffffffffff
error: invalid address argument "0xffffffffffffffff": (null)
```
One byte before gives me a 1 byte unmapped range:
```
(lldb) memory region 0xfffffffffffffffe
lldb < 38> send packet: $qMemoryRegionInfo:fffffffffffffffe#73
lldb < 34> read packet: $start:fffffffffffffffe;size:1;#63
[0xfffffffffffffffe-0xffffffffffffffff) ---
```
Which is all to say, this doesn't really give us much hint other than perhaps WASM could use the addressable bits infrastructure to set what it's maximum address can be. Though there may be uses in WASM for addresses outside that range, special functions perhaps, I'm no expert here.
One solution is to change WAMR to respond with the requested address instead of its default value. Then update LLDB to handle the size being 0 and document that as a way to signal that the range is above the virtual address size (on the assumption that everyone starts their addresses at 0).
But given that it seems there's usually only one region anyway, I doubt anyone will be inconvenienced by this. Filing this anyway since I had to think it through to come to that conclusion.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
