Re: [lldb-dev] [llvm-dev] Running lit (googletest) tests remotely

[David Blaikie via lldb-dev]

On Wed, May 31, 2017 at 10:44 AM Matthias Braun via llvm-dev <
llvm-...@lists.llvm.org> wrote:

>
> > On May 31, 2017, at 4:06 AM, Pavel Labath  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  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 capability: During
> >>> test discovery phase, we could copy the required files to the remote
> >>> host. Then, when we run the test, we could just prefix the run command
> >>> similarly to how it is done for running the tests under valgrind. It
> >>> would be up to the user to provide a suitable command for copying and
> >>> running files on the remote host (using rsync, ssh, telnet or any
> >>> other transport he chooses).
> >>
> >> This seems to be the crux to me: What does "required files" mean?
> >> - All the executables mentioned in the RUN line? What llvm was compiled
> as a library, will we copy those too?
> > For executables, I was considering just listing them explicitly (in
> > lit.local.cfg, I guess), although parsing the RUN line should be
> > possible as well. Even with RUN parsing, I expect we would some way to
> > explicitly add files to the copy list (e.g. for lldb tests we also
> > need to copy the program we are going to debug).

>
> > As for libraries, I see a couple of solutions:
> > - declare these configurations unsupported for remote executions
> > - copy over ALL shared libraries
> > - have automatic tracking of runtime dependencies - all of this
> > information should pass through llvm_add_library macro, so it should
> > be mostly a matter of exporting this information out of cmake.
> > These can be combined in the sense that we can start in the
> > "unsupported" state, and then add some support for it once there is a
> > need for it (we don't need it right now).
> Sounds good. An actively managed list of files to copy in the lit
> configuration is a nice simple solution provided we have some regularily
> running public bot so we can catch missing things. But I assume setting up
> a bot was your plan anyway.
>
> >
> >> - Can tests include other files? Do they need special annotations for
> that?
> > My initial idea was to just copy over all files in the Inputs folder.
> > Do you know of any other dependencies that I should consider?
> I didn't notice that we had already developed a convention with the
> "Inputs" folders, so I guess all that is left to do is making sure all
> tests actually follow that convention.
>

The Google-internal execution of LLVM's tests relies on this property - so
at least for the common tests and the targets Google cares about, this
property is pretty well enforced.


>
> >
> >>
> >> As another example: The llvm-testsuite can perform remote runs
> (test-suite/litsupport/remote.py if you want to see the implementation)
> that code makes the assumption that the remote devices has an NFS mount so
> the relevant parts of the filesystem look alike on the host and remote
> device. I'm not sure that is the best solution as NFS introduces its own
> sort of flakiness and potential skew in I/O heavy benchmarks but it avoids
> the question of what to copy to the device.
> >
> > Requiring an NFS mount is a non-starter for us (no way to get an
> > android device to create one), although if we would be able to hook in
> > a custom script which does a copy to simulate the "mount", we might be
> > able to work with it. Presently I am mostly thinking about correctness
> > tests, and I am not worried about benchmark skews
>
> Sure, I don't think I would end up with an NFS mount strategy if I would
> start fresh today. Also the test-suite benchmarks (esp. the SPEC) ones tend
> to have more complicated harder to track inputs.
>
> - Matthias
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] A bit of extra-polish for my lldb plugin

[Nat! via lldb-dev]

Pavel, this is pretty much exactly what happens. (Except that there is 
no frontend. The substitution is done during CodeGen. But that is just a 
detail)


I think a more general solution, that doesn't tie mulle-objc implicitly 
to the dwarf format would be better in the long term though.


Ciao
Nat!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] A bit of extra-polish for my lldb plugin

[Pavel Labath via lldb-dev]

On 31 May 2017 at 19:40, Jim Ingham  wrote:
> Pavel, can you say more about your idea?
>
> In both ObjC and C++ methods, you can refer to an ivar either as "this->ivar" 
> or just "ivar".  But the DWARF for C++ doesn't tell lldb that a particular 
> language supports referring to ivars transparently this way.  It will say 
> that the "this" parameter is artificial, and that it is the "object pointer". 
>  But it doesn't so far as I can tell record the fact that elements of that 
> parameter can be transparently accessed.
>
> I think it would be confusing for the debug information to record the 
> transparently accessed ivars as pseudo-locals, the duplication would confuse 
> folks, and that isn't how they are understood by the person writing the code. 
>  It might be good to propose a "DW_AT_transparent" attribute, and mark the 
> ivars or maybe the parameter that way.  I guessing that wasn't done because 
> it was assumed that the debugger would know this sort of rule from the 
> language in question.
>
> As I understand it, problem here is that Nat's runtime has extra rules for 
> transparent access that lldb doesn't know about.
>

I understood the problem differently, although I can't really say
whether it was correct or not. My impression was that the members of
the "_param" struct were **parameters** to the method, which have
become (due to some source code transformations, or ABI
considerations) members of a single struct parameter. So a programmer
would write (i'm not going to try to write this in objc)

int foo(int x, int y) { return x+y; }

and the some frontend would transform this into:

struct foo_params {int x,y;};
int foo(foo_params *_param) { return _param->x + _param->y; }

before passing it into the real compiler.

If this is the case then I think it makes sense to have the dwarf
describe the original source code, and not the intermediate form.
However, if it's something else, then that's likely not a good idea,
and I should probably shut up, as I obviously don't know enough about
objc to be of help here.

cheers,
pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev