Re: again: ping: testcase for "absolute source" patch

Daniel Jacobowitz
2005-05-05T18:52:09Z

On Thu, May 05, 2005 at 01:00:48PM +0200, Baurzhan Ismagulov wrote:
> Hello,
>
> the recent discussion reminded me about the testcase I submitted in
> http://sources.redhat.com/ml/gdb-patches/2004-08/msg00539.html . While
> unrelated, it did help me understand the issue. There are relatively few
> basic cases (like absolute / relative, compilation cwd present / absent,
> etc., search path specified / not specified, etc.), it's their
> permutations that kill. While the testcase doesn't cover them all, I
> think it's a good start, especially if we are going to touch some
> functionality affecting openp. The functionality is very basic and
> breaks everything if anything goes wrong; it happened several times in
> the past, thus the motivation for this testcase.

We don't plan to touch openp right now; but let's test it, by all
means.

> A short history: Michael Chastain was guiding me w.r.t. this testcase.
> Basically, he had three issues with it:
>
> 1. The testcase didn't support build != host.
>
> The overall consensus was that there were useful testcases that
> didn't support build != host at the moment. Michael decided to
> include them if they explicitly returned unresolved on remote hosts.
> I added the check.

Lately we've been caring about this even less.

> 3. There were four cases where I was not sure what we wanted to do, so I
> marked them "fail".
>
> I asked for feedback several times, but haven't received any answer.

Adding new FAILs is not ok; at a minimum they should have a PR filed
and be KFAIL'd. But let's take a brief check to see what the logical
thing to do would be. Here's the reference:

http://sources.redhat.com/ml/gdb-patches/2004-08/msg00539.html

If I understand the test right - which is hard to do, definitely -
these cases look like:

cd $a
gcc -g -o $b/openp.bin openp.c
mv openp.c $c/$a/openp.c
(gdb) dir $c
(gdb) file $b/openp.bin

And then you fail because we didn't search for the absolute path $a
relative to $c, which is in our search path.

I don't think there's much value to this, if $cdir is an absolute path.
If it's a relative path, maybe, but your compiler oughtn't to be doing
that. Can you explain why you think this should work?

I do know of some problems with openp that are sort of like this - I
encounter them periodically debugging glibc. They're a little similar
but related, and you might want to add tests for them. Here's one:

drow@nevyn:~/dir% pwd
/home/drow/dir
drow@nevyn:~/dir% cat 1/1.c
#include <../2/2.h>

int main()
{ return 0; }
drow@nevyn:~/dir% cat 2/2.h
int foo() { return 1;}
drow@nevyn:~/dir% (cd 1 && gcc -g -o 1 1.c -I.)
drow@nevyn:~/dir% (cd 1 && gdb 1)
...
(gdb) list foo
1 int foo() { return 1;}
drow@nevyn:~/dir% gdb ./1/1
...
(gdb) list foo
1 2.h: No such file or directory.
in 2.h
(gdb) info source
Current source file is 2.h
Compilation directory is ../2

...

Current source file is 1.c
Compilation directory is /home/drow/dir/1

We've lost the fact that "../2" is relative to the compilation
directory for the main source file; I'm not sure if this is a dwarf2
reader bug or a symtab bug or an openp bug. But it bugs me. A lot.

> So, I suggest that we review, polish and include this testcase. After
> that, we can test it on more platforms and add new permutations for
> non-POSIX names.
>
> Comments?

You're including pathnames in the test results. I'd really rather you
didn't do that; it makes results hard to compare, and really really
hard to read. Also, a lot of the tests have shortened names like "s1"
but those names don't tell the reader anything. So in some places you
need to be less descriptive and in others more descriptive. Ideally I
can fit the descriptions on a screen (80-col plus or minus a bit) and
yet still have some idea what they are testing.

--
Daniel Jacobowitz
CodeSourcery, LLC