Regression tests for ctf reader: Avoid duplicating files

[Guillermo Martinez]

On Tuesday, November 9, 2021 8:47:43 AM CST Dodji Seketeli wrote:

Hello Dodji and Jose,

Thanks for your advices!
> Hello Guillermo and Jose,
> 
> Sorry for my late reply.
> 
> Guillermo Martinez via Libabigail <libabigail@sourceware.org> a écrit:
> 
> > On Thursday, November 4, 2021 2:27:57 AM CST Jose E. Marchesi wrote:
> >
> > Hello libabigail team,
> >> 
> >> > I'm working in the implementation of regression tests for ctf reader
> >> > (tests/test-read-ctf.cc), it's very similar to test-read-dwarf.cc, so
> >> > they have some C and header source files that are common among
> >> > them, e.g:
> >> >
> >> >       tests/data/test-read-ctf/PR27700/include-dir/priv.h
> >> >       tests/data/test-read-ctf/PR27700/include-dir/pub.h
> >> >       tests/data/test-read-ctf/PR27700/pub-incdir/inc.h
> >> >       tests/data/test-read-ctf/PR27700/test-PR27700.c
> >> >       tests/data/test-read-ctf/test-PR26568-1.c
> >> >       tests/data/test-read-ctf/test-PR26568-2.c
> >> >
> >> > So, we're planning move those common source file to:
> >> >
> >> > tests/data/test-read-common/
> 
> Great.
> 
> >> > But we still need *two different* binary files with the debugging
> >> > information: DWARF (-gdwarf) and CTF (-gctf), that they would 
> >> > need to be recompiled. The current implementation to test ctf reader
> >> > use binary files previously compiled, so there is one file for 
> >> > each binary format:
> >> >    
> >> >      tests/data/test-read-*ctf*/test-PR26568-1.o
> >> >      ...
> >> >      tests/data/test-read-*dwarf*/test-PR26568-1.o
> >> >
> >> > So, Are you agree with this approach?
> >> >
> >> > We are looking for the way to avoid duplicating files :-)
> >> >
> >> > Thanks in advanced for your comments!
> 
> On Thursday, November 4, 2021 2:27:57 AM CST Jose E. Marchesi wrote:
> 
> 
> >> An alternative to have two copies of compiled objects is to have just
> >> one copy (in test-read-common) compiled with both -gdwarf -gctf.
> 
> Right, we could do that too.  You'll thus need to adjust the existing
> tests in test-read-dwarf.cc to make them pick their data from
> test-read-common instead, e.g:
> 
> This:
> 
>   {
>     "data/test-read-dwarf/test0",
>     "",
>     "",
>     SEQUENCE_TYPE_ID_STYLE,
>     "data/test-read-dwarf/test0.abi",
>     "output/test-read-dwarf/test0.abi"
>   },
> 
> would be changed into:
> 
>   {
>     "data/test-read-common/test0",
>     "",
>     "",
>     SEQUENCE_TYPE_ID_STYLE,
>     "data/test-read-common/test0.abi",
>     "output/test-read-common/test0.abi"
>   },

hmmm.. as far as I could see at the end of tests/test-read-dwarf.cc
there is an assert test invoking the diff command for two ABIs files
one of them is generated by reading the ELF file (InOutSpec.in_elf_path)
and it is serialized in InOutSpec.out_abi_path and the other one is
the predefined file stored in InOutSpec.in_abi_path. I'm nor pretty
sure how can I store "common" ABIs for both formats (CTF & DWARF) in
in_abi_path, since out_abi_path file is just generated with information
depending of which test we are running: tests/test-read-dwarf.cc
or tests/ttests/test-read-ctf.cc, and the diff command will fail.

I think that in data/test-read-common/ we can just store the source file
and the compiled file with both (-gctf & -gdwarf) ABIs file should be stored
in a separate file one for each debug format.

What do you think?

Worth it mention here that I found a couple of test that generate the XML ABI corpus
*same information* but the XML nodes *are not* in the *same order* ... and the
diff command fails :-( ..I'm not plenty sure but we could read the input XML ABI
(InOutSpec.in_abi_path) and build the corpus, after that compare this one with
the corpus built with ELF file (InOutSpec.in_elf_path) and so avoid rely to diff
command, something like to abidw --abidiff works


> 
> The tests/data/Makefile.am will also need some adjustments.
> 
> I think that sounds a fair path to take, as far as I am concerned.
> 
> > Thanks Jose for your advice! .. any other alternative? .. I would like to start
> > working on this :-)
> 
> Great.  If you see that you need to share code between
> tests/test-read-ctf.cc and tests/test-read-dwarf.cc, maybe you can just
> create a tests/test-read-common.{h,cc} files, if that helps.  This will
> obviously be welcome, unless someone objects to it, of course :-)

Totally agree! :-)

> Cheers,
Thank so much for your comment!

Kind Regards
Guillermo