similar to: Running lit (googletest) tests remotely

> On May 31, 2017, at 4:06 AM, Pavel Labath <labath at google.com> wrote: > > Thank you all for the pointers. I am going to look at these to see if > there is anything that we could reuse, and come back. In the mean > time, I'll reply to Mathiass's comments: > > On 26 May 2017 at 19:11, Matthias Braun <mbraun at apple.com> wrote: >>> Based on a

Thank you all for the pointers. I am going to look at these to see if there is anything that we could reuse, and come back. In the mean time, I'll reply to Mathiass's comments: On 26 May 2017 at 19:11, Matthias Braun <mbraun at apple.com> wrote: >> Based on a not-too-detailed examination of the lit codebase, it does >> not seem that it would be too difficult to add this

Hi, Tests in compiler-rt run under both iOS simulators and Android devices, which requires “wrapping” the run line with the “adb” command for Android, and adding a prefix / setting some environment variables for simulators/ In case of Android this is done by changing the compilation command to produce a wrapper which already calls “adb”, and in case of iOS simulators by explicitly adding the

Hi Pavel, I was thinking about a generic proposal for a while, but then I’ve realized that a much simpler heuristic suffices for all of my needs: - Prepend all commands which should execute on the device with %run, which runs a wrapper python script - Inside that script use a simple regexp to find all paths - sync all paths to the device - run the executable on the device - sync all paths

Hello George, I would be very much interested in a (generic) solution that would allow running tests on a remote host/device. My intended use case for this is lldb+android, and I am mostly interested in googletest-style tests. In fact, I proposed something vaguely similar to this (but limited to gtest) last year <http://lists.llvm.org/pipermail/llvm-dev/2017-May/113370.html>. However, due

On Thu, 14 Jun 2018 at 19:26, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Jun 14, 2018 at 11:24 AM Pavel Labath <labath at google.com> wrote: >> >> On Thu, 14 Jun 2018 at 17:58, Greg Clayton <clayborg at gmail.com> wrote: >> > >> > >> > >> > On Jun 14, 2018, at 9:36 AM, Adrian Prantl <aprantl at

oh, awesome. Were you using type units? (I imagine that'd make the situation worse - since the way clang emits DWARF for a type with a member function template implicit specialization is to emit the type unit without any mention of this, and to emit the implicit specialization declaration into the stub type in the CU (that references the type unit)) Without type units I'd be pretty

On Thu, Feb 9, 2017 at 2:23 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 9 Feb 2017, at 01:33, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: >> >> 4.0.0-rc2 was just tagged from the branch at r294535. > > Building on FreeBSD 10 at least didn't crash this time, and lld built just fine. :) I uploaded the following: >

On 28/01/2020 20:37, David Blaikie via llvm-dev wrote: > and one idea I had was to have the DWARFDataExtractor return a new > DWARFDataExtractor that was specifically bounded to the parsed length > for this reason. I think this would be great. In fact, I was getting ready to propose something like that myself. :) FWIW, lldb DataExtractors already support this kind of slicing. pl

On June 22, 2017 at 5:51:39 AM, Pavel Labath (labath at google.com) wrote: I don't have any concrete feedback, but: - +1 for removing the "FastDemagler" - If you already construct an AST as a part of your demangling process, would it be possible to export that AST for external consumption somehow? Right now in lldb we sometimes need to parse the demangled name (to get the

Hello all, In <https://reviews.llvm.org/D41986#977215> it was brought up that there are at least two parties interested in having DWARF5 accelerator tables implemented, so I'm writing this email to see if there's anyone else interested in this topic, and to try to synchronize our efforts. Our interest for this stems from a desire to make dwarf parsing fast on non-apple targets

This is Greg's area, he'll be able to answer in detail how the name chopper gets used. IIRC it chops demangled names, so it is indirectly a client of the demangler, but it doesn't use the demangler to do this directly. Name lookup is done by finding all the base name matches, then comparing the context. We don't do a very good job of doing fuzzy full name matches - for instance

On 04/03/2020 21:45, Jim Ingham via llvm-dev wrote: > As you have seen, different machine architectures do different things after hitting a trap. On x86_64, the trap instruction is executed, and then you stop, so the PC is left after the stop. On arm64, when execution halts the pc is still pointing at the trap instruction. > > I don't think lldb should be in the business of telling

Hello again, It's been nearly six months since my first email, so it's a good time to recap what has been done here so far. I am happy to report that stages 1-3 (i.e. producer/consumer in llvm and integration with lldb) of my original plan are now complete with one caveat. The caveat is that the .debug_names section is presently not a full drop-in replacement for the .apple_*** sections.

Dear testers, Start your engines; 6.0.0-rc1 was just tagged. I know there are still open blockers and it's early in the process in a way, but I'd like to find out where we are. Please run the test script, let me know the results, and upload binaries. Thanks, Hans

+LLDB Dev <lldb-dev at lists.llvm.org> as well for visibility. +Pavel Labath <labath at google.com> since he and I have talked about such things. On Mon, Aug 31, 2020 at 7:26 PM David Blaikie <dblaikie at gmail.com> wrote: > [+debug info folks, just as FYI - since the immediate question's more > about 3rd party library deps than the nuances of DWARF, etc] > >

On Thu, 14 Jun 2018 at 17:58, Greg Clayton <clayborg at gmail.com> wrote: > > > > On Jun 14, 2018, at 9:36 AM, Adrian Prantl <aprantl at apple.com> wrote: > > > > On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thank you all. I am going to try to reply to all comments in a single email. > >

On 25/06/2019 11:24, James Henderson via llvm-dev wrote: > Hi Alex, > > Would you recommend that I do what is done in > unittest/ObjectYAML/MinidumpYAMLTest.cpp which just uses a string > inside the source file, or use an Inputs directory? Both are not > great, as you point out about using an Inputs directory > > > I'd be inclined to go with the

Is the plan for LLDB to just adapt the code that is trying to follow the new code style or also the code using the LLDB code style? I’m in general in favor of moving LLDB to the LLVM code style because it makes the LLDB code that interfaces with Clang/LLVM less awkward to write (e.g. no more code style confusion when inheriting from a Clang classes inside the LLDB code base). But I think if we do

Hello all, I am looking into using LLVM streams more extensively in LLDB (which currently rolls it's own stream classes). One of the things that's missing for me to be able to do that is the ability to open a file with the O_CLOEXEC flag (to prevent us leaking file descriptors into the debugged process). So I tried adding a F_NonInheritable flag to the raw_fd_ostream constructor, which