This is an archive of the discontinued LLVM Phabricator instance.

Allow setting multiple debug types
ClosedPublic

Authored by evgeny777 on Dec 25 2016, 9:21 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

evgeny777 updated this revision to Diff 82479.Dec 25 2016, 9:21 AM
evgeny777 retitled this revision from to Allow setting multiple debug types .
evgeny777 updated this object.
evgeny777 added reviewers: greened, gribozavr.
evgeny777 set the repository for this revision to rL LLVM.
evgeny777 added a project: lld.
evgeny777 added subscribers: ikudrin, grimar.
davide edited edge metadata.Dec 25 2016, 9:36 AM

Do you plan to use this somewhere? Is there a way to test this behaviour?

Thanks for looking at it.
I'm using llvm libraries in a sample application and on some occasions would like to print debug output from more than one module, like this:

setCurrentDebugTypes({"dyld", "regalloc"});

Currently I can't do this because setCurrentDebugType() allows debugging only one module
Unfortunately I don't have a clue how to write unit test for this, but I think the change is straightforward.

Thanks for looking at it.
I'm using llvm libraries in a sample application and on some occasions would like to print debug output from more than one module, like this:

setCurrentDebugTypes({"dyld", "regalloc"});

Currently I can't do this because setCurrentDebugType() allows debugging only one module
Unfortunately I don't have a clue how to write unit test for this, but I think the change is straightforward.

Maybe you can try writing a unit test, no?

Maybe you can try writing a unit test, no?

Do you have an idea how to do this? This is C++ library function not invoked anywhere inside llvm. I tried to find any test for *setCurrentDebugType(const char *)* (existing one), but looks like there is none either.

Maybe you can try writing a unit test, no?

Do you have an idea how to do this? This is C++ library function not invoked anywhere inside llvm. I tried to find any test for *setCurrentDebugType(const char *)* (existing one), but looks like there is none either.

You can probably model it after any other unit test for the code living in Support/. If the original function is not tested, it's probably worth a test for that as well, if you don't mind/have bandwidth for. If you still can't find it, I'll provide a pointer.
Sorry for being a little pedantic here, but it's not uncommon for me to go around and remove code considered "dead" in the tree (because unused/untested) and 6 months later receive a mail from somebody with an out-of-tree backend/code complaining I broke their product. So, keeping in-tree tests is at least a way to differentiate between code that's obviously dead and code that's used by somewhere but doesn't live in-tree.

evgeny777 edited edge metadata.Dec 26 2016, 5:24 AM
evgeny777 added a subscriber: llvm-commits.
evgeny777 updated this revision to Diff 82503.Dec 26 2016, 7:12 AM

Added unit test. Thanks for a hint!

davide accepted this revision.Dec 26 2016, 7:16 AM
davide edited edge metadata.

LGTM. Thanks for your patience.

This revision is now accepted and ready to land.Dec 26 2016, 7:16 AM
This revision was automatically updated to reflect the committed changes.