test-in-container: Moving a test to a particular location *before* execution?

test-in-container: Moving a test to a particular location *before* execution?

[Carlos O'Donell]

DJ,

In developing tests for dynamic string token substitution
in DT_RUNPATH, DT_PRATH and LD_PRELOAD etc, I found that
$ORIGIN is hard to test because I want this kind of behaviour:

(a) Create the chroot.
(b) Move the test into the chroot into the $ORIGIN expected location.
(c) Run the test in the container.

The (c) part doesn't work like I expect because test-container
is running the binary relative to the build path.

I think I might need some kind of env var like TEST_RUN_FROM=/path/
where the binary is copied into the path and then the $filename is
executed from that path.

Does that make sense?

For DSOs and other files I can move them all into the chroot by
using the setup script, but the executable can't be moved like
that because the target of execution is given to test-container by
the makefile target.

-- 
Cheers,
Carlos.

Re: test-in-container: Moving a test to a particular location *before* execution?

[DJ Delorie]

You mean something that copies the test to a specified location, and
execs that instead of the in-build one?

I suppose the easiest way to implement that is to add yet another
command to the setup script, like this:

  exec /bin/foo

which means "whatever you were about to exec, copy it to this path, and
exec that instead"

Bonus: if the destination path ends in "/", append the basename of the
specified test.

Re: test-in-container: Moving a test to a particular location *before* execution?

[Carlos O'Donell]

On 12/10/19 2:42 PM, DJ Delorie wrote:
> 
> You mean something that copies the test to a specified location, and
> execs that instead of the in-build one?

Yes.
 
> I suppose the easiest way to implement that is to add yet another
> command to the setup script, like this:
> 
>   exec /bin/foo

I like it.

> which means "whatever you were about to exec, copy it to this path, and
> exec that instead"
> 
> Bonus: if the destination path ends in "/", append the basename of the
> specified test.

Sure, it avoids needing to keep the test name in sync in the file.

-- 
Cheers,
Carlos.

Re: test-in-container: Moving a test to a particular location *before* execution?

[DJ Delorie]

Is there ever going to be a case where the program we exec is *not* the
test we just built?

Or do we define the testsuite that way?

Re: test-in-container: Moving a test to a particular location *before* execution?

[Carlos O'Donell]

On 12/10/19 3:28 PM, DJ Delorie wrote:
> 
> Is there ever going to be a case where the program we exec is *not* the
> test we just built?

I don't think so...
 
> Or do we define the testsuite that way?
 
Exactly.

Today we define:
- How a test is built.
  - CFLAGS, LDFLAGS, object it is built with.
- How a test is run.
  - env vars.
  - But not where a test is run from.

I could have used a script wrapper and a special test to do
all of this work manually, but that seems silly.

The *only* thing we're missing from the above is:

  - Where does the test run from?
    - Location of executable relative to new installed glibc.

Nominally this is extracted from the location of the binary
in the build tree, and that's not useful for many path related
tests e.g. DST $ORIGIN.

If the program we exec is *not* the test we just built, then
the solution is to rewrite the test to *make it* the program
we will exec. If not, then you're just going to use the script
file to copy the secondary binary into the right place, and the
first binary (perhaps the same binary) just re-execs itself from
the right location (something I didn't want to have to do for all
such tests).

Thoughts?

-- 
Cheers,
Carlos.

Re: test-in-container: Moving a test to a particular location *before* execution?

[DJ Delorie]

I was thinking "would we ever need to run ld.so in the container
anyway, and need that ld.so to be pid 1?"

Like:

/lib64/ld.so --some-flags tst-the-test.elf

but I suppose you can still exec() ld.so from the test.

Re: test-in-container: Moving a test to a particular location *before* execution?

[Carlos O'Donell]

On 12/10/19 3:48 PM, DJ Delorie wrote:
> 
> I was thinking "would we ever need to run ld.so in the container
> anyway, and need that ld.so to be pid 1?"
> 
> Like:
> 
> /lib64/ld.so --some-flags tst-the-test.elf
> 
> but I suppose you can still exec() ld.so from the test.

Oh! Yes. Yes we would. But running the loader itself is a weird
degenerate use case... thanks for thinking of that :-)

-- 
Cheers,
Carlos.