Re: [DynInst_API:] commit: v9.0.x and v9.1.x branches

[Josh Stone <jistone@xxxxxxxxxx>]

On 10/22/2015 01:24 PM, Bill Williams wrote:
> On 10/22/2015 03:21 PM, Josh Stone wrote:
>> On 10/22/2015 11:58 AM, Bill Williams wrote:
>>> Reorganized Monday's commits into 9.0.x (everything but the module
>>> changes) and 9.1.x (module changes only, thus far) branches. They'll
>>> both get merged back to master post-releases.
>> Better, thanks!
>>
>> There's one more break that snuck into v9.0.x:
>>
>> $ git diff v9.0.3 */h/
>> diff --git a/symtabAPI/h/Symtab.h b/symtabAPI/h/Symtab.h
>> index 078a1d5304f8..babbe5a8eb14 100644
>> --- a/symtabAPI/h/Symtab.h
>> +++ b/symtabAPI/h/Symtab.h
>> @@ -363,8 +363,8 @@ class SYMTAB_EXPORT Symtab : public LookupInterface,
>>
>>      std::string getDefaultNamespacePrefix() const;
>>
>> -   unsigned getNumberofRegions() const;
>> -   unsigned getNumberofSymbols() const;
>> +   unsigned getNumberOfRegions() const;
>> +   unsigned getNumberOfSymbols() const;
>>
>>      std::vector<std::string> &getDependencies();
>>      bool removeLibraryDependency(std::string lib);
> Consistency fix to match the documentation. Should we include a "wrong" 
> wrapper as well?

"Wrong" is a matter of perspective.  In the world of ABIs, documentation
is trumped by what's really in the library.

It's less bad to just add the new symbols, no matter which looks like a
wrapper in the actual implementation.  Then old binaries still work with
the new library, and just new binaries using the new symbols won't work
with old libraries.

If you also use symbol versioning, then RPM can express that version
dependency beyond simple sonames.  That's how glibc has added new stuff
without having changed sonames in a long time.  But dyninst isn't using
symbol versions anywhere afaik.

Still, I'd lean toward a doc fix for now, and update the code later.

>>
>> I don't object this in later sonames, but for now it's an ABI break.
>>
>> I'll use libabigail's abidiff to see if there's anything else, but I
>> think my simple header diff is probably good enough.
>