Contributing debug visualizers for libc++

Hi,

Chromium now uses a statically linked libc++ on most platforms. One piece of feedback we got from devs is that they don’t want the switch to libc++ to impede their debugging experience, so we wrote a natvis file that teaches Microsoft’s debuggers how to display libc++ types. We’re also using https://github.com/koutheir/libcxx-pretty-printers to achieve the same for gdb.

Other projects are probably also interested in having good libc++ support in their debuggers. Would there be interest to have these debug visualizers right in the libc++ repository, either somewhere in utils/, or in a new misc/ directory, or what have you?

We’d gladly contribute the natvis file [1] under LLVM’s license.

(libcxx-pretty-printers is a separate project not done by us. If this thread goes somewhere, I’m planning to ask the upstream maintainers if they’d be open to relicensing and contributing the gdb pretty printers to upstream libcxx as well, but they might not agree. If they don’t, we (chromium) might want to write libc++ pretty printers for gdb from scratch and contribute those, but not sure.)

Nico

1: https://cs.chromium.org/chromium/src/tools/win/DebugVisualizers/libc%2B%2B.natvis?q=%5C.natvis&sq=package:chromium&dr=C&l=144

Nico –

I’m going to apologize in advance for a slow response, since I (and Louis) are at C++Now this week.
This sounds really interesting, and I’ll take a look at this early next week.

– Marshall

Thanks for the quick response! No rush, next week sounds great :slight_smile:

Sorry about the additional email, but the file has moved around. The new location is at https://cs.chromium.org/chromium/src/build/config/c%2B%2B/libc%2B%2B.natvis?q=file:libc…natvis&sq=package:chromium&g=0&l=1

Friendly ping :slight_smile:

Relatedly Sterling has been working with people on gdb pretty printers
and so having a place in the libc++ sources would be great. :slight_smile:

Also things like testing that they don't break should be at least
thought about a little bit.

-eric

We have been on a bit of a sprint for gdb libc++ pretty printers over the last week or two. We have a reasonable set right now, with more coming. And a very good test harness and set of tests too.

We would love to get a good upstreaming story here, and it is high on my list of priorities.

What do the tests look like? Is that something that we can reasonably run as part of the libc++ test suite?

Louis

Yes. I would upstream the tests them as part of upstreaming the printers. I’m working on this.

I’m assuming the tests need GDB in order to run – is that correct? I assume you’ll put up a Phab review when you’re ready?

Louis

Yes they will need gdb to run, and we will go through the full review process with all of it.

I’m working on this today. Question:

What directories would be best for the python package and the associated tests? They don’t seem to fit well in any current directories.

If gdb isn’t installed on the machine, should they fail or not run? There are tradeoffs with both approaches.

Getting them shipped to actual users is a different can of worms, but we can look at that when we actually have something to work with.

I’m working on this today. Question:

What directories would be best for the python package and the associated tests? They don’t seem to fit well in any current directories.

Under libcxx/test, we could add a new directory like libcxx/test/gdb. We need to keep this out of the directories normally considered by lit, but I think that’s the only hard requirement.

If gdb isn’t installed on the machine, should they fail or not run? There are tradeoffs with both approaches.

They should not run unless there’s a compelling reason to do otherwise. We don’t want to tie passing the libc++ test suite to having gdb installed!

Note that whatever approach we use, it would be nice if we could use the same approach for the lldb formatters once/if the LLDB folks decide to send them our way.

Louis

You should be able to sniff in lit.local.config whether (a new enough) gdb is installed and mark the tests unsupported if not. Unsupported is better than xfail here.

You should be able to sniff in lit.local.config whether (a new enough) gdb is installed and mark the tests unsupported if not. Unsupported is better than xfail here.

This assumes that the tests are even using lit. I don’t know whether that’s the case. Let’s wait for the PR to be up!

Louis

I’ve just sent https://reviews.llvm.org/D65609 for review.

It obviously needs to figure out how to tell if gdb is present. I’m not sure how to communicate from find_program inside cmake all the way down into UNSUPPORTED in the test file, but that is a minor detail.

There are a lot of judgement calls on how things look. We tried to match libstdc++ where possible.

Also, happy to change directories or whatever.

We also need to figure out how to ship it to users. libstdc++.so uses a .debug_gdb_scripts section to point to an absolute path where it is installed. Static linking is trickier.

Thanks a lot. Let’s follow up on the Phabricator review.

Louis