Dealing with release mode

Dodji Seketeli dodji@seketeli.org
Fri Jan 1 00:00:00 GMT 2016


Hello Michi,

Michi Henning <michi.henning@canonical.com> a écrit:

[...]

> I’ve integrated abigail into our test suite, and this is working
> nicely, thanks!

I am glad to hear that.  Thanking you for taking the time to engage with
us.  I hope the software is going to get better thanks to this
interaction.

> One thing I have to deal with is that the unit tests may be run with
> release mode locally, in which case the binaries are compiled without
> -g.

I see.

> I can run abidw on the shared lib, but the ABI dump that is generated
> doesn’t contain any useful info for doing a real ABI compliance
> test. When I run
>
>     abidiff baseline_with_debug_dump current_without_debug_dump
>
> abidiff tells me that everything is fine. This is awkward because it
> gives me a possibly false negative. The code that was compiled might
> indeed break the ABI but, because it was compiled without -g, abidiff
> gives the wrong answer.

I see.  There are some users who wants abidiff to behave "normally" even
when there is no debug info.  In that case, it just tells you about
added/removed symbols.

But I see your point.  Let's try to address this issue then.

[...]

> It would be nice if abidw could do something more useful here, such as
> returning a dedicated exit status if the library wasn’t compiled with
> -g.

[...]

> Similarly, it would be nice if abidiff would check if one or both of
> the .so or .xml files that are provided were created without debug
> info and return a dedicated exit status. That way, I could just test
> for that status and do whatever is appropriate in my test driver.

Right.  I guess we could add a --require-debug-info option to abidiff,
or something like that.

When that option is provided, if the debug info data is empty, abidiff
would return an exit code made of the flag ABIDIFF_EMPTY_DEBUG_INFO (a
new value, possibly 16).

This new use case would be different from the already supported use case
of not *finding* the debug info, for instance when the --debug-info-dir*
options are provided.  In this already supported use case, the tool flat
out returns an ABIDIFF_ERROR code (value 1).

Would that work for you?

If yes, then I guess we are good to file an enhancement request for this
task.

Cheers,

-- 
		Dodji



More information about the Libabigail mailing list