[PATCH] D88988: [llvm-symbolizer] Add inline stack traces for Windows.

Wed Dec 2 00:42:44 PST 2020

jhenderson added a subscriber: probinson.
jhenderson added a comment.

In D88988#2426218 <https://reviews.llvm.org/D88988#2426218>, @MaskRay wrote:

> In D88988#2426055 <https://reviews.llvm.org/D88988#2426055>, @dblaikie wrote:
>
>> In D88988#2424937 <https://reviews.llvm.org/D88988#2424937>, @jhenderson wrote:
>>
>>> (Taking out-of-line since the comment thread has rather diverged from the original thing)
>>>
>>>> Perhaps - I'd be happy to widen the use case of debuginfo-tests for other things like symbolizing. And if the existing interactive debugger parts weren't Windows suitable/of interest, I'd be OK with it being possible to run those symbolizer bits without the interactive debugger bits. But would provide a space for a full clang+lld+llvm-symbolizer test cases, which currently can't be done in either the clang or lld repository, for instance.
>>>
>>> We've internally been considering a need for an "integration" lit-based testsuite that is able to test the interactions in tools that would otherwise not really fit in one or the other location. We have our own downstream non-lit based test repository, but for some tests this is too heavyweight, and it would be nice to test things more locally. Examples include showing, for example, that tools can consume debug data produced by clang (note that because defaults might change as to what version of DWARF is emitted, an llvm-mc assembly or YAML based test here wouldn't be appropriate), or similarly for relocations being handled by the downstream tools. The intent here is not to replace targeted lit tests, but rather to show that end-to-end behaviour is still sensible.
>>>
>>> Maybe this idea could be useful upstream? It would need the ability to create a lit-based testsuite, probably as a separate top-level directory in the llvm-project tree, which can use components from all projects. We'd want REQUIRES support that could be used to say `REQUIRES: clang` or similar so that users could still run the subset of tests that work with the projects they build.
>>
>> Yeah - I'd probably first suggest that such tests could go into debuginfo-tests, though if it's meant to extend to things other than debug info - yeah, another top level repo might be suitable. Maybe even the test-suite itself, though that's a bit of a dark place and maybe a distinct place with narrower, pure lit based testing would be beneficial.
>
> An integration style testing for llvm-symbolizer (both clang and lld are allowed) sounds good to me. The current llvm-symbolizer tests for ELF mostly focus on relocatable objects. There are very few shared object/executable targeted tests.

I've made a note on our internal issue tracker item for our integration suite idea, to keep an eye on this. I don't if or when we'll get around to it, so if somebody else wants to get the ball rolling, just let me know what people have done and I can update our tracker accordingly, to make sure we don't duplicate effort. I guess the first stage would be to propose and RFC.

A couple of notes in case anybody picks this up: 1) @probinson mentioned on our internal issue tracker that there was an end-to-end round table discussion that touched on this topic at the 2019 developers meeting, so there's probably some wider interest outside those involved in this discussion. 2) I think it needs to be integrated with the `check-all` target, so that people and bots will run it properly.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88988/new/

https://reviews.llvm.org/D88988