Re: [PATCH] asan unit tests from llvm lit-test

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Dec 03, 2012 at 11:09:07AM -0800, Mike Stump wrote:
> On Dec 3, 2012, at 3:00 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> > Mike, CCing you especially on the proposed lib/gcc-dg.exp dg-env-var
> > changes and I have one question about cleanup of files (file delete
> > vs. remote_file target (or is that host or build) delete).
> > But of course if you could eyeball the rest and comment, I'd be even happier.
> 
> >> +file delete dlclose-test-1.exe-so.so
> >> +file delete shared-lib-test-1.exe-so.so 
> > 
> > Ah, it is here, but wonder what it will do for cross testing.
> > Shouldn't that be remove_file ? delete where ? is either target, or host, or
> > build (not sure which one).  Mike?
> 
> Sounds about right.

E.g. cleanup-dump uses remove-build-file, so maybe we should use that.

> >> #
> >> @@ -287,6 +327,10 @@ proc search_for { file pattern } {
> >> # as c-torture does.
> >> proc gcc-dg-runtest { testcases default-extra-flags } {
> >>     global runtests
> >> +    global set_env_var
> >> +
> >> +    # Init set_env_var
> >> +    set set_env_var [list]
> >> 
> >>     # Some callers set torture options themselves; don't override those.
> >>     set existing_torture_options [torture-options-exist]
> > 
> > For this, I'd appreciate Mike's input.
> 
> When documented, it will say if you want to change the environment
> variables on the host, target or build machines.  When it says which one,
> it will be apparent when tested, if it does as documented.  Since I don't
> know what you guys want to do (better not to imagine one thinks they
> know)â I'd leave it to you guys to figure it out and test.  Also, if
> untested, I'd not see any reason for it to work; but, maybe I'm just
> cautious that way.  If you can only test native, just bail out if not
> native, and try and recruit someone that can test canadian or cross.

The env vars are used by the target libs when running the test executable.
So, are you suggesting we name it dg-set-target-env-var instead of
dg-set-env-var, so that in the future we can also have
dg-set-{host,build}-env-var?

> >  If it is useful for all tests
> > generally (I'd say it is, we could use it e.g. for testing some of the
> > libgomp env vars), then it should stay here or so, otherwise it would need
> > to be moved into asan-dg.exp and have asan in the name.
> > 
> > More importantly, I'm wondering about dg-env-var vs. cross testing, I guess
> > env var is set on host only, not remotely set on the target.  So, either
> > we should mark all tests that use dg-env-var with some special effective
> > target that would be basically [is_native]
> 
> Ick, no.
> 
> > - or what is the way to limit tests to native testing only,
> 
> roughly:
> 
> if [is3way] || ! [isnative]
> 	return

Or if [is_remote target] ?  As Wei's dg-set-env-var implementation is
in the ${tool}_load override, we need to return something, so probably
if [is_remote target]
  return [list "unsupported" ""]
or so (of course, only if any dg-set-target-env-var directives have been
actually seen in the testcase).

	Jakub