Re: [Valgrind-developers] testing debug info reading

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

>           Nicholas Nethercote <nj...@cs...> wrote:
> > So I was wondering about the idea of keeping some pre-compiled binaries
> > in the test suite to improve its coverage.  Any reason why this wouldn't
> > work?  Perhaps you'd want to use static binaries, which would then be
> > fairly large...

It's a good question.

> You don't have to precompile them, just make sure you use -gstabs
> or -gstabs+ when building them to force stabs debugging.

That's true, but that would then expose you to the vagaries of whatever
the compiler in question decided to emit into the stabs, which would mean
it wasn't really clear what was being tested.  How about adding to the
repo a .so which is made just once -- so we know exactly what it tests,
and kept the same forever.  The test can then dlopen it, which will make
V read the debug info.  This gives us a fixed test without having to
incorporate a huge static binary.  V can then run code inside the
.so, which presumably does a variety of Bad Things which memcheck
reports, and so the reported line numbers on those error messages
should match known-good values.

Hmm.  Interesting idea in general.  We spent way too much time 
fixing up trivial differences in backtraces in the regtest suite,
and this provides at least a partial way to insulate ourselves from
such variation.

J