As executable tests, they fail spectacularly in a cross-build environment. And you need some sort of debugger with GDB-like commands and output (or have some front end to your debugger that imitates that) in order to run them. I think they would need to stay in a separate project because of those requirements. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David Blaikie via llvm-dev Sent: Thursday, September 07, 2017 11:26 AM To: Zachary Turner; llvm-dev Subject: Re: [llvm-dev] Status of debuginfo-tests It's used, but not a huge repository of things, as you can see. I think I've run it once or twice, but a long time ago. It was introduced for/by Apple/LLDB stuff, so it's not something I've paid much attention to. It's probably not suitable as part of llvm tests directly. Those tests are designed to be shorter/narrower/more focussed than full integration tests (we don't execute any compiled programs under test there, for example). Porting to lit seems probably fine/good. On Thu, Sep 7, 2017 at 11:23 AM Zachary Turner <zturner at google.com<mailto:zturner at google.com>> wrote: What is the status of debuginfo-tests? Is it actively supported? How do you run it? It doesn't appear to be based on lit, any particular reason? Why is it its own repo instead of being part of llvm repo? I'd like improve this to support CodeView and PDB, such that it would only run on Windows and only if a suitable debugger was found (probably WinDbg). WinDbg supports a JavaScript-based scripting model, similar to how LLDB supports a Python based model, so my thoughts were to have a lit-based runner that scans for .js files that contain a test script alongside some source, then build the program, run it in WinDbg with some script that does various things, and exits the debugger, moving on to the next test. Anything I should be aware of / careful of when messing around in here? And any reason it can't be moved to llvm/tests and ported to lit? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170907/2dc6d2d6/attachment.html>
To be clear, the tests I'm proposing will have no resemblance whatsoever to GDB, so I would be intentionally forking the set of tests in this regards. So there would very clearly be a paradigm shift in writing CodeView debug info tests (which would be written in JavaScript using WinDbg specific debugger commands) and DWARF debug info tests (which would be written in whatever / using GDB style commands) On Thu, Sep 7, 2017 at 11:34 AM Robinson, Paul <paul.robinson at sony.com> wrote:> As executable tests, they fail spectacularly in a cross-build > environment. And you need some sort of debugger with GDB-like commands and > output (or have some front end to your debugger that imitates that) in > order to run them. I think they would need to stay in a separate project > because of those requirements. > > --paulr > > > > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *David > Blaikie via llvm-dev > *Sent:* Thursday, September 07, 2017 11:26 AM > *To:* Zachary Turner; llvm-dev > *Subject:* Re: [llvm-dev] Status of debuginfo-tests > > > > It's used, but not a huge repository of things, as you can see. I think > I've run it once or twice, but a long time ago. It was introduced for/by > Apple/LLDB stuff, so it's not something I've paid much attention to. > > It's probably not suitable as part of llvm tests directly. Those tests are > designed to be shorter/narrower/more focussed than full integration tests > (we don't execute any compiled programs under test there, for example). > > Porting to lit seems probably fine/good. > > > > On Thu, Sep 7, 2017 at 11:23 AM Zachary Turner <zturner at google.com> wrote: > > What is the status of debuginfo-tests? Is it actively supported? How do > you run it? It doesn't appear to be based on lit, any particular reason? > Why is it its own repo instead of being part of llvm repo? > > > > I'd like improve this to support CodeView and PDB, such that it would only > run on Windows and only if a suitable debugger was found (probably > WinDbg). WinDbg supports a JavaScript-based scripting model, similar to > how LLDB supports a Python based model, so my thoughts were to have a > lit-based runner that scans for .js files that contain a test script > alongside some source, then build the program, run it in WinDbg with some > script that does various things, and exits the debugger, moving on to the > next test. > > > > Anything I should be aware of / careful of when messing around in here? > And any reason it can't be moved to llvm/tests and ported to lit? > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170907/059a7402/attachment.html>
> On Sep 7, 2017, at 11:37 AM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > To be clear, the tests I'm proposing will have no resemblance whatsoever to GDB, so I would be intentionally forking the set of tests in this regards. So there would very clearly be a paradigm shift in writing CodeView debug info tests (which would be written in JavaScript using WinDbg specific debugger commands) and DWARF debug info tests (which would be written in whatever / using GDB style commands)That sounds like an unfortunate direction. Can you explain why it wouldn't be possible to write a wrapper (in JavaScript) that interprets the 3ish gdb commands used by the tests in terms of WinDbg? Similar to how LLDB is supported? -- adrian> > On Thu, Sep 7, 2017 at 11:34 AM Robinson, Paul <paul.robinson at sony.com <mailto:paul.robinson at sony.com>> wrote: > As executable tests, they fail spectacularly in a cross-build environment. And you need some sort of debugger with GDB-like commands and output (or have some front end to your debugger that imitates that) in order to run them. I think they would need to stay in a separate project because of those requirements. > > --paulr > > <> > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org <mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of David Blaikie via llvm-dev > Sent: Thursday, September 07, 2017 11:26 AM > To: Zachary Turner; llvm-dev > Subject: Re: [llvm-dev] Status of debuginfo-tests > > > > It's used, but not a huge repository of things, as you can see. I think I've run it once or twice, but a long time ago. It was introduced for/by Apple/LLDB stuff, so it's not something I've paid much attention to. > > It's probably not suitable as part of llvm tests directly. Those tests are designed to be shorter/narrower/more focussed than full integration tests (we don't execute any compiled programs under test there, for example). > > Porting to lit seems probably fine/good. > > > > On Thu, Sep 7, 2017 at 11:23 AM Zachary Turner <zturner at google.com <mailto:zturner at google.com>> wrote: > > What is the status of debuginfo-tests? Is it actively supported? How do you run it? It doesn't appear to be based on lit, any particular reason? Why is it its own repo instead of being part of llvm repo? > > > > I'd like improve this to support CodeView and PDB, such that it would only run on Windows and only if a suitable debugger was found (probably WinDbg). WinDbg supports a JavaScript-based scripting model, similar to how LLDB supports a Python based model, so my thoughts were to have a lit-based runner that scans for .js files that contain a test script alongside some source, then build the program, run it in WinDbg with some script that does various things, and exits the debugger, moving on to the next test. > > > > Anything I should be aware of / careful of when messing around in here? And any reason it can't be moved to llvm/tests and ported to lit? > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170907/3579a268/attachment.html>