[Lldb-commits] [PATCH] D69106: MemoryRegion: Print "don't know" permission values as such
Pavel Labath via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Fri Oct 18 04:42:19 PDT 2019
labath marked an inline comment as done.
labath added a comment.
In D69106#1712949 <https://reviews.llvm.org/D69106#1712949>, @clayborg wrote:
> Looks good. Do we maybe want to use "unknown" instead of "don't know" when printing out the long for of a MemoryRegionInfo::OptionalBool? Or maybe "???"?
"don't know" is the name of the enum, and the same thing that the formatter printed previously. I don't think this value is be printed anywhere right now (except maybe some test failure messages), but if you want (I agree the name is somewhat informal), I can rename the change the enum and the formatter string at the same time.
================
Comment at: test/Shell/Minidump/memory-region-from-module.yaml:22
# CHECK1: [0x0000000000004000-0x00000000000040b0) r-x {{.*}}memory-region-from-module.exe PT_LOAD[0]
-# TODO: This output does not give any indication that the region is only "potentially" writable.
-# CHECK2: [0x0000000000004000-0x0000000000004010) rwx
+# CHECK2: [0x0000000000004000-0x0000000000004010) r??
# ALL-LABEL: (lldb) memory region 0x5000
----------------
clayborg wrote:
> How do we get two responses for a single address here?
These are two separate checks for the two FileCheck invocations above. The test runs the same lldb commands on two minidumps (their yaml below) which differ only in that the second one has a MemoryList stream covering the 0x4000 area. The test shows that in the first case (no MemoryList) we get the permissions from the module while in the second one, the minidump data "wins". (In this case I'm not really concerned with who wins, as that shouldn't happen in practice -- I'm mainly interested in making sure that we don't end up with a corrupted/overlapping memory regions)
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D69106/new/
https://reviews.llvm.org/D69106
More information about the lldb-commits
mailing list