Page MenuHomePhabricator

[lldb] Show flags for memory regions
Needs ReviewPublic

Authored by DavidSpickett on Thu, Sep 10, 2:20 AM.



This extends the "memory region" command to
show flags such as those found in /proc/smaps
on Linux.

(lldb) memory region addr
[0x00007ffff7ed3000-0x00007ffff7fd3000) rw- /dev/zero (deleted)
flags: me mr ms mw rd sd sh wr

  • Added an optional "flags" field to the qMemoryRegion packet
  • "memory region" command will show flags where possible
  • HasFlags and GetFlags added to Python API for memory regions
  • Added testing for Linux proc maps parsing

Flags are represented as strings, space seperated when
together. This is done to account for differences
between OS naming. (versus inventing some generic
set of names)

For now we'll just show the information to the user.
Future HasSomeFlag() methods can check for spellings
based on platform.

Only Linux /proc/smaps parsing is supported in this initial
change. Targets that don't have or currently support this
information can leave out the field and it won't be shown
in the command output.
(API users can check HasFlags() for this)

Diff Detail

Event Timeline

DavidSpickett created this revision.Thu, Sep 10, 2:20 AM
Herald added a project: Restricted Project. · View Herald TranscriptThu, Sep 10, 2:20 AM
DavidSpickett requested review of this revision.Thu, Sep 10, 2:20 AM

This is in support of AArch64 memory tagging support as described here:
See "### Extending qMemoryRegion"

smaps format described here:
Support not added to minidumps, this would need doing in breakpad itself first (

General strategy is to keep the flags as strings so that we don't have to invent a new enum/bitfield value each time one is added. Plus we get to give some value by showing them all to the user without special support.

Later, I'll be adding a HasMemoryTagging() method to the region to use for memory tagging commands, something like:

bool HasMemoryTagging() {
  return m_flags && (m_flags->find("mt") != m_flags->end());

If BSD/MacOS/Windows had a different naming you could either check for both (if not overlapping with anything else), or add a platform argument to decide what to look for.

DavidSpickett added a reviewer: omjavaid.EditedThu, Sep 10, 2:33 AM

What isn't covered in testing is checking that "memory region" will not print "flags:" if there was no flag info. This would need a way to make a fake lldbserver that didn't reply with the flags field, I could write tests that expect the "flags:" but then when you ran them on a different kernel they might fail.

Perhaps there is a way to replay a gdb comms session to lldb instead?

This seems fine to me with some minor nits. Also do you plan on writing a Linux API test for this which test memory regions on Linux? I couldnt locate one already written.


This function always returns true. If there is no other use of HasFlags API function then may be merge GetFlags and HasFlags by returning false in case flags are not available.


May be consider converting this into a class enum.


This file apparently requires a clang-format run.

  • clang-format Minidump file
  • Remove HasFlags from API, return True/False from GetFlags instead
  • Rename MapKind to MapsKind and make it an enum class
DavidSpickett marked 3 inline comments as done.Tue, Sep 15, 2:30 AM

This seems fine to me with some minor nits. Also do you plan on writing a Linux API test for this which test memory regions on Linux? I couldnt locate one already written.

There are some tests in test/API/tools/lldb-server/ that parse region packets manually (e.g. qMemoryRegionInfo_reports_code_address_as_executable) but they're not using the API.

There is no test for "memory region" or the API. I'll add some to test/API/linux/, one for Kernels with smaps, one without. (so you'll only run one or the other per platform)