Changes to libsframe ABI

[Indu Bhagat <indu.bhagat@oracle.com>]

Hi,

I have been contemplating a change to the libsframe ABI which is 
breaking it in theory, but should be fine in practice. I need some 
inputs on whether this is OK to do.

I would like to make an existing API sframe_get_funcdesc_with_addr () 
static. The interface provided by this function is not a healthy 
abstraction to expose: the return type is sframe_func_desc_entry, which 
is defined in include/sframe.h (the SFrame binary format definition). 
This ties up the library in a undesirable way.  Most importantly, this 
function should technically not be directly necessary for _any_ external 
customer, like a stack tracer.  A stack tracer should only need to do a 
sframe_find_fre ().

I would like to make it static because this API should only be needed 
(and used) internally in the library, at least in the current form.

Is it okay to make such a change ?  The first release of libsframe was 
Binutils 2.40. I do not expect any users of 
sframe_get_funcdesc_with_addr () out there currently. IMO, this is OK to 
do. WDYT ?

A larger question still looms over as well: The library is young at this 
time, and making guarantees of a stable ABI in the current shape looks 
limiting to me. Apart from the above change, I would also like to make 
some further changes to other existing APIs (which will also break the 
ABI). How can this be managed without causing pain ?

Thanks,
Indu