Subject: Detailed symbols.map

From: Daniel van Vugt <[email-masked]>
Date: Wed, 26 Aug 2015 14:30:06 +0800

If... we specified the complete function prototype for each C++ entry in 
symbols.map (where the C++ symbol encodes its parameter types), then we 
would be able to detect ABI breaks automatically as a build failure. 
Instead of having to keep a keen eye on changes to include/*

Just a thought.

---

From: Robert Ancell <[email-masked]>
Date: Wed, 26 Aug 2015 07:49:39 +0000

Couldn't you just add .symbols files into debian/? Then the debuild would
automatically fail until they were correctly updated.

On Wed, Aug 26, 2015 at 7:30 AM Daniel van Vugt <[email-masked]> wrote:

> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 26 Aug 2015 15:52:57 +0800

Might work, but it would be better to avoid creating a second redundant 
list, and to be able to detect breaks earlier with a simple "make". 
That's assuming the symbols in question are exercised sufficiently in 
tests and demos. Otherwise a break might still go unnoticed.

On 26/08/15 15:49, Robert Ancell wrote:
> Couldn't you just add .symbols files into debian/? Then the debuild
> would automatically fail until they were correctly updated.
>
> On Wed, Aug 26, 2015 at 7:30 AM Daniel van Vugt <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 26 Aug 2015 17:40:08 +0800

We can script character translation easily enough.

And your concern about how to make it foolproof when fools are so 
ingenious is a reasonable point, but not a new problem. We had the same 
problem with the old checksum tests.

I guess the way we want to and should maintain ABIs is that the contents 
of a stanza MIR_SERVER_N { } never changes (although you can always add 
a new stanza MIR_SERVER_N+1 with changes). So store a historical copy of 
existing "ABIs" such as MIR_SERVER_N and compare to make sure its 
contents never change (if still present at all).

On 26/08/15 16:06, Alan Griffiths wrote:
> On 26/08/15 07:30, Daniel van Vugt wrote:
>> If... we specified the complete function prototype for each C++ entry
>> in symbols.map (where the C++ symbol encodes its parameter types),
>> then we would be able to detect ABI breaks automatically as a build
>> failure. Instead of having to keep a keen eye on changes to include/*
>>
>> Just a thought.
>>
>
> This might detect some failures. But we'd need to write a filter to deal
> with all the characters the symbols.map parser doesn't like.
>
> But I fear that all that would happen is that the symbols.map would be
> updated to fix the build.
>

---

From: "Stephen M. Webb" <[email-masked]>
Date: Wed, 26 Aug 2015 06:24:38 -0400

On Wed, Aug 26, 2015 at 5:40 AM, Daniel van Vugt
<[email-masked]> wrote:
> I guess the way we want to and should maintain ABIs is that the contents of
> a stanza MIR_SERVER_N { } never changes (although you can always add a new
> stanza MIR_SERVER_N+1 with changes). So store a historical copy of existing
> "ABIs" such as MIR_SERVER_N and compare to make sure its contents never
> change (if still present at all).

That's how libstdc++ does it, and they've done a pretty good job of
maintaining ABI copatibility for about 15 years (GCC-5
notwithstanding: sometimes you just have to break ABI).  This has to
be done in conjunction with an additional check tool, though, which is
why a symbols version file is used in the sources *and*
dpkg-gensymbols is used in the packaging on Debian-based systems.
Libstdc++ actually uses its own tool during the build to look for
missing symbol changes at build time.

This is a false security, though, because most of the insidious ABI
changes do not show up as symbol name changes.

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 27 Aug 2015 10:05:48 +0800

That's true. If someone adds a field to a struct or changes the size of 
a bool, symbol names don't change. Even worse; how do you communicate 
that myprojectN uses libstdc++M? In a past life I actually went to the 
trouble of putting out different binary releases for libc5 systems vs 
libc6. So another hidden part of your ABI is "what other C/C++ library 
ABIs does it depend on?".

What I've been suggesting however is aimed at solving precisely the kind 
of ABI break that mir-team keeps landing and reviewers not noticing.

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Thu, 27 Aug 2015 13:26:09 +1000

On Thu, Aug 27, 2015 at 12:05 PM, Daniel van Vugt 
<[email-masked]> wrote:
> That's true. If someone adds a field to a struct or changes the size 
> of a bool, symbol names don't change. Even worse; how do you 
> communicate that myprojectN uses libstdc++M? In a past life I 
> actually went to the trouble of putting out different binary releases 
> for libc5 systems vs libc6. So another hidden part of your ABI is 
> "what other C/C++ library ABIs does it depend on?".
> 
> What I've been suggesting however is aimed at solving precisely the 
> kind of ABI break that mir-team keeps landing and reviewers not 
> noticing.

I'm not entirely sure what problem you're trying to solve here? We 
regularly break - and bump - ABIs, and that's fine.

We *also* have the abi-check target which is strictly better than 
symbols.map at finding these things - it also finds structure size 
changes and enumeration numbering differences, for example.

We've talked about having abi-check run as an advisory test on all MPs 
for a while. Now that JaaS is mostly here, maybe that would solve the 
problem?

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 27 Aug 2015 11:30:43 +0800

That's the problem. We don't have abi-check automated yet. Although we 
don't have to limit ourselves to that.

What we do have is regular ABI breaks landing and nobody noticing. So I 
audit the code manually and propose the missing breaks. Fortunately the 
whole team is getting on board and noticing them more often, but it's 
still not automated.

On 27/08/15 11:26, Christopher James Halse Rogers wrote:
>> communicate that myprojectN uses libstdc++M? In a past life I actually
>> went to the trouble of putting out different binary releases for libc5
>> systems vs libc6. So another hidden part of your ABI is "what other
>> C/C++ library ABIs does it depend on?".
>>
>> kind of ABI break that mir-team keeps landing and reviewers not noticing.
>

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Thu, 27 Aug 2015 13:37:49 +1000

On Thu, Aug 27, 2015 at 1:30 PM, Daniel van Vugt 
<[email-masked]> wrote:
> That's the problem. We don't have abi-check automated yet. Although 
> we don't have to limit ourselves to that.
> 
> What we do have is regular ABI breaks landing and nobody noticing. So 
> I audit the code manually and propose the missing breaks. Fortunately 
> the whole team is getting on board and noticing them more often, but 
> it's still not automated.

And why is this a problem? We run abi-check as a part of the release 
process, and the ABI breaks (by and large) haven't broken CI (or the 
branch wouldn't have landed).

It would be *preferable* to bump ABI along with the branch that breaks 
it, but what is the problem if it isn't?

We know a *good* solution - automating abi-check - is reasonably close 
to implementable and should be reasonably cheap to implement. Is the 
problem so urgent that we should spend effort on an inferior stop-gap?

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 27 Aug 2015 11:54:08 +0800

Doing it in the release process is inefficiently late. Obviously it 
would be preferable to notice breaks before the release is attempted so 
as to now slow it down.

And if abi-check is run as part of the release process, are the results 
stored anywhere? They don't seem to be in CI so it must be separate to 
that...
    https://code.launchpad.net/~mir-team/mir/0.15/+merge/269082

If anyone has any further info, please update:
    https://bugs.launchpad.net/mir/+bug/1451733