debugserver does not expose `name:` attribute in memory region info

[patryk4815]

On macOS, when querying memory regions via LLDB and debugserver, the name: attribute is often missing from memory region packets.

Currently, debugserver only provides the type: field (e.g., type:malloc-metadata or type:heap), but this information is not accessible via the Python API (SBMemoryRegionInfo has no GetType() method).

In pwndbg we want to display meaningful memory region names/types for the user (e.g., [heap], [stack], [malloc-metadata]).
But since debugserver does not provide name:, and Python cannot access type:, scripts cannot display human-readable memory page names.

(lldb) script
>>> regions = lldb.process.GetMemoryRegions()
# Example packets where type is present but name is missing
<  87> read packet: $start:100020000;size:4000;permissions:r;dirty-pages:100020000;type:malloc-metadata;#00
<  88> read packet: $start:100024000;size:4000;permissions:rw;dirty-pages:100024000;type:malloc-metadata;#00

>>> region = lldb.SBMemoryRegionInfo()
>>> regions.GetMemoryRegionAtIndex(7, region)
True
>>> region.GetName()
None

Expected behavior

• Debugserver should implement the name: attribute in gdb-remote memory region packets.

• Debugserver should implement more memory mapping names, eg:

  • [shared memory] - (user_tag == 0 && share_mode in (SM_SHARED, SM_TRUESHARED, SM_SHARED_ALIASED))
  • [VM_ALLOCATE] - (user_tag == 0 && share_mode in (SM_PRIVATE, SM_PRIVATE_ALIASED))
  • [Kernel Alloc Once] - (user_tag == VM_MEMORY_OS_ALLOC_ONCE)
  • [stack]
  • [heap]
  • [malloc-metadata]
  • or more from XNU VM_* types - https://github.com/apple-oss-distributions/xnu/blob/8d741a5de7ff4191bf97d57b9f54c2f6d4a15585/osfmk/mach/vm_statistics.h#L581-L785

• relevant place in debugserver:

  llvm-project/lldb/tools/debugserver/source/MacOSX/MachVMRegion.cpp

  Lines 186 to 225 in c894d3a

  	std::vector<std::string> MachVMRegion::GetMemoryTypes() const {
  	std::vector<std::string> types;
  	if (m_data.user_tag == VM_MEMORY_STACK) {
  	if (m_data.protection == VM_PROT_NONE) {
  	types.push_back("stack-guard");
  	} else {
  	types.push_back("stack");
  	}
  	}
  	if (m_data.user_tag == VM_MEMORY_MALLOC) {
  	if (m_data.protection == VM_PROT_NONE)
  	types.push_back("malloc-guard");
  	else if (m_data.share_mode == SM_EMPTY)
  	types.push_back("malloc-reserved");
  	else
  	types.push_back("malloc-metadata");
  	}
  	if (m_data.user_tag == VM_MEMORY_MALLOC_NANO ||
  	m_data.user_tag == VM_MEMORY_MALLOC_TINY ||
  	m_data.user_tag == VM_MEMORY_MALLOC_SMALL ||
  	m_data.user_tag == VM_MEMORY_MALLOC_LARGE ||
  	m_data.user_tag == VM_MEMORY_MALLOC_LARGE_REUSED ||
  	m_data.user_tag == VM_MEMORY_MALLOC_LARGE_REUSABLE ||
  	m_data.user_tag == VM_MEMORY_MALLOC_HUGE ||
  	m_data.user_tag == VM_MEMORY_REALLOC ||
  	m_data.user_tag == VM_MEMORY_SBRK ||
  	m_data.user_tag == VM_MEMORY_SANITIZER) {
  	types.push_back("heap");
  	if (m_data.user_tag == VM_MEMORY_MALLOC_TINY) {
  	types.push_back("malloc-tiny");
  	}
  	if (m_data.user_tag == VM_MEMORY_MALLOC_LARGE) {
  	types.push_back("malloc-large");
  	}
  	if (m_data.user_tag == VM_MEMORY_MALLOC_SMALL) {
  	types.push_back("malloc-small");
  	}
  	}
  	return types;
  	}

How it looks like in pwndbg:

In pwndbg we forked lldb, and it looks like this, but our changes are too bad for upstream:

[llvmbot]

@llvm/issue-subscribers-lldb

Author: None (patryk4815)

On macOS, when querying memory regions via LLDB and debugserver, the `name:` attribute is often missing from memory region packets.

Currently, debugserver only provides the type: field (e.g., type:malloc-metadata or type:heap), but this information is not accessible via the Python API (SBMemoryRegionInfo has no GetType() method).

In pwndbg we want to display meaningful memory region names/types for the user (e.g., [heap], [stack], [malloc-metadata]).
But since debugserver does not provide name:, and Python cannot access type:, scripts cannot display human-readable memory page names.

(lldb) script
>>> regions = lldb.process.GetMemoryRegions()
# Example packets where type is present but name is missing
&lt;  87&gt; read packet: $start:100020000;size:4000;permissions:r;dirty-pages:100020000;type:malloc-metadata;#<!-- -->00
&lt;  88&gt; read packet: $start:100024000;size:4000;permissions:rw;dirty-pages:100024000;type:malloc-metadata;#<!-- -->00

&gt;&gt;&gt; region = lldb.SBMemoryRegionInfo()
&gt;&gt;&gt; regions.GetMemoryRegionAtIndex(7, region)
True
&gt;&gt;&gt; region.GetName()
None

Expected behavior

• Debugserver should implement the name: attribute in gdb-remote memory region packets.

• Debugserver should implement more memory mapping names, eg:

  • [shared memory] - (user_tag == 0 && share_mode in (SM_SHARED, SM_TRUESHARED, SM_SHARED_ALIASED))
  • [VM_ALLOCATE] - (user_tag == 0 && share_mode in (SM_PRIVATE, SM_PRIVATE_ALIASED))
  • [Kernel Alloc Once] - (user_tag == VM_MEMORY_OS_ALLOC_ONCE)
  • [stack]
  • [heap]
  • [malloc-metadata]
  • or more from XNU VM_* types - https://github.com/apple-oss-distributions/xnu/blob/8d741a5de7ff4191bf97d57b9f54c2f6d4a15585/osfmk/mach/vm_statistics.h#L581-L785

• relevant place in debugserver:

  llvm-project/lldb/tools/debugserver/source/MacOSX/MachVMRegion.cpp

  Lines 186 to 225 in c894d3a

  	std::vector<std::string> MachVMRegion::GetMemoryTypes() const {
  	std::vector<std::string> types;
  	if (m_data.user_tag == VM_MEMORY_STACK) {
  	if (m_data.protection == VM_PROT_NONE) {
  	types.push_back("stack-guard");
  	} else {
  	types.push_back("stack");
  	}
  	}
  	if (m_data.user_tag == VM_MEMORY_MALLOC) {
  	if (m_data.protection == VM_PROT_NONE)
  	types.push_back("malloc-guard");
  	else if (m_data.share_mode == SM_EMPTY)
  	types.push_back("malloc-reserved");
  	else
  	types.push_back("malloc-metadata");
  	}
  	if (m_data.user_tag == VM_MEMORY_MALLOC_NANO ||
  	m_data.user_tag == VM_MEMORY_MALLOC_TINY ||
  	m_data.user_tag == VM_MEMORY_MALLOC_SMALL ||
  	m_data.user_tag == VM_MEMORY_MALLOC_LARGE ||
  	m_data.user_tag == VM_MEMORY_MALLOC_LARGE_REUSED ||
  	m_data.user_tag == VM_MEMORY_MALLOC_LARGE_REUSABLE ||
  	m_data.user_tag == VM_MEMORY_MALLOC_HUGE ||
  	m_data.user_tag == VM_MEMORY_REALLOC ||
  	m_data.user_tag == VM_MEMORY_SBRK ||
  	m_data.user_tag == VM_MEMORY_SANITIZER) {
  	types.push_back("heap");
  	if (m_data.user_tag == VM_MEMORY_MALLOC_TINY) {
  	types.push_back("malloc-tiny");
  	}
  	if (m_data.user_tag == VM_MEMORY_MALLOC_LARGE) {
  	types.push_back("malloc-large");
  	}
  	if (m_data.user_tag == VM_MEMORY_MALLOC_SMALL) {
  	types.push_back("malloc-small");
  	}
  	}
  	return types;
  	}

How it looks like in pwndbg:

In pwndbg we forked lldb, and it looks like this, but our changes are too bad for upstream:
<img width="805" height="525" alt="Image" src="https://github.com/user-attachments/assets/0ee73538-2392-497a-9701-fe5f1f4a856b" />

[DavidSpickett]

I did a bit of my own digging, and the "name" Linux provides is whatever the kernel decides to put into /proc/maps and/or /proc/smaps. Sometimes this is the file backing the memory, sometimes it's "stack"/"heap", whatever. Anonymous mappings can also be named by user code in recent kernels.

So in most cases, it's not that the mapping has a literal name inside the kernel. From what I read about XNU, no mappings have a name. So I'm not sure that debugserver can make an assumption about what the "name" is, and it may be better to give clients access to the type(s) and they can decide what to do with them (which is #155692).

Including LLDB itself. I don't see region names in memory region --all on my Mac.

@jasonmolenda / @JDevlieghere what do you think?

[DavidSpickett]

@jasonmolenda / @JDevlieghere ping

Re-reading my previous comment, I think the answer here might be that name just doesn't make sense to implement on XNU. Maybe just the newer named regions. Can you confirm that?

[jasonmolenda]

It seems like this would be duplicating the functionality of the vmmap tool from the Instruments suite, which can describe memory segments to this granularity. (the current VM segment categorization in debugserver that was needed by lldb was all copied from that tool)

I'm not sure if adding that level of memory region description to debugserver/lldb is the right choice given the existence of a tool focused especially on that. "read only" tools like vmmap and sample can run on a process that is currently being debugged by lldb (unlike a "read write" style tool like lldb, which only one can attach at a time)

[DavidSpickett]

Ok so unlikely to be something anyone from Apple would implement in debugserver. Better in some ways to not confuse things by having another implementation that might be slightly different.

That said, GDB is able to get some information in some form from somewhere so it is possible to do. Someone could contribute an implementation if they want to (or for #155692).

In the meantime, if you (@patryk4815) are doing local debugging you could invoke this vmmap tool or run it as a shell command from LLDB. Not sure that is going to work when directly connected to a debugserver though, I know when connected to a platform you can run shell commands on the remote. Also I don't know if there's an API call equivalent to the command.

Then try to parse its output (https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/VMPages.html).