This is an archive of the discontinued LLVM Phabricator instance.

MemoryRegion: Print "don't know" permission values as such
ClosedPublic

Authored by labath on Oct 17 2019, 5:31 AM.

Details

Summary

The permissions in a memory region have ternary states (yes, no, don't
know), but the memory region command only prints in binary, treating
"don't know" as "yes", which is particularly confusing as for instance
the unwinder will treat an unknown value as "no".

This patch makes is so that we distinguish all three states when
printing the values, using "?" to indicate the lack of information. It
is implemented via a special argument to the format provider for the
OptionalBool enumeration.

Diff Detail

Event Timeline

labath created this revision.Oct 17 2019, 5:31 AM

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 "???"?

test/Shell/Minidump/memory-region-from-module.yaml
22 ↗(On Diff #225410)

How do we get two responses for a single address here?

labath marked an inline comment as done.Oct 18 2019, 4:40 AM

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.

test/Shell/Minidump/memory-region-from-module.yaml
22 ↗(On Diff #225410)

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)

clayborg accepted this revision.Oct 18 2019, 9:55 AM

Sounds good, thanks for doing this

This revision is now accepted and ready to land.Oct 18 2019, 9:55 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptNov 5 2019, 2:18 AM