This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch 1/4] unwinder: New base address based dwfl_report_elf_baseaddr


On Mon, 2013-03-18 at 14:09 -0700, Roland McGrath wrote:
> > I haven't found any users of dwfl_report_elf outside the elfutils code
> > base. But that doesn't mean there aren't any. Is there any way we can
> > let the user signal they want the new semantics? Maybe have the module
> > name argument have some prefix or suffix. Or is that even uglier?
> 
> That is laughably ugly.  You are such a joker, I'm sure you didn't mean it.

:) Yeah, lets pretend I didn't mean that.

> What I had in mind was something like making the function take two
> arguments, e.g. "GElf_Addr base, bool add_p_vaddr".  So N, true would
> mean the old semantics.  That has the benefit that the API changes in
> a compile-breaking way, so nobody will just recompile and not notice
> their program being broken if it was right before.
> 
> It's a bit ugly for a function interface, especially if nobody ever
> actually wants the old behavior.  But keeping the same signature for
> different semantics means silent change on recompile, creating
> confusion (probably much later).

OK, that is indeed nicer. A pity it breaks source compatibility. But you
are right that people that do use this function now might not really
know/want the semantics it currently has.

> Of course, we also need not to break old binaries with a new DSO.  
> But that is easy enough with symbol versioning.

If I understand the NEW_VERSION and COMPAT_VERSION macros (as used with
dwfl_module_build_id) correctly then that indeed seems easy.

Thanks,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]