Re: [Valgrind-developers] RFC: formalize .exp file names

[Julian S. <js...@ac...>]

Interesting.  For sure something better than what we have now would
be good.  Your proposal seems a bit complex, but I haven't digested
all the details yet.

> PLATFORM := x86 | x86-linux | x86-darwin | amd64 | arm | ppc32 | ppc64 |
> s390x

That gives a terminological inconsistency with how "platform" is used
in the rest of the code base.  The factoring used is

  arch -- cpu architecture, eg, x86, arm, etc
  os   -- the OS (often as a proxy for the ABI): linux, darwin

Then platform is an (arch,os) pairing.  This is the basis of the
preprocessor symbols VGA_<arch>, VGO_<os> and VGP_<arch>_<os>.
Recently I had to add "platform variant" so as to do Android, which
is very similar to arm-linux, but not identical, using
VGPV_<arch>_<os>_<variant>, where "variant" is normally "vanilla".

Anyway .. it would be nice to maintain terminological consistency w.r.t
"platform" as it is already used.


> The matching in vg_regtest would start with the most specialized exp
> file towards the generic one and it would stop as soon as a match is
> obtained. E.g. when looking for a stderr exp file for foo.vgtest while
> running on x86 Linux, vg_regtest would attempt to match in this order:
> 
> foo.stderr.exp-x86-linux.*
> foo.stderr.exp-x86-*
> foo.stderr.exp-32bit-*
> foo.stderr.exp-*

Doesn't this assume that you can always uniquely identify a
"most specialised exp file"?  IOW, you're saying that the set of exp files
forms a finite partial order which has both a top point (least specialised,
foo.stderr.exp) and a bottom point (most specialised).  But what if you
have the following 3 files:

foo.stderr.exp-x86
foo.stderr.exp-linux
foo.stderr.exp

What's the most-specialised exp file here?  I think the idea is a good
one, but you need to nail down the semantics a bit.

Also, your approach implies that the perl driver script will have the
ability to compute these partial ordering relations on the exp filenames,
which sounds a bit complex.

How do other variants fix it?  For example just the other day, we had to
do a new-glibc vs older-glibc .stdout.exp split (because of problems with
-ve nan printing iirc).

J