|
From: Nicholas N. <nj...@cs...> - 2005-07-23 12:52:51
|
Hi, The recent action in the stabs reader got me thinking -- it's a part of Valgrind that's really hard to regularly test, because most (all?) of the nightly tests will use DWARF. 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... N |
|
From: Tom H. <to...@co...> - 2005-07-23 12:55:52
|
In message <Pin...@ch...>
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...
You don't have to precompile them, just make sure you use -gstabs
or -gstabs+ when building them to force stabs debugging.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-07-23 15:56:10
|
> 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 |
|
From: Tom H. <to...@co...> - 2005-07-23 16:24:01
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> > 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.
Putting the assembly output from the compiler in is another option
as that preserves the stabs that the compiler generated whilst still
being text. That said subversion should handle binary files better.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-25 00:19:51
|
On Sat, 23 Jul 2005, Tom Hughes wrote: >>> 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. > > Putting the assembly output from the compiler in is another option > as that preserves the stabs that the compiler generated whilst still > being text. That said subversion should handle binary files better. These are interesting ideas, and beyond what I intended... I was just thinking of retaining all the C tests, but having one or two binaries (or shared objects) containing examples of weird stabs stuff that has caused problems. This would be platform-specific, which is one reason against over-using it. N |