This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: [patch 1/4] unwinder: New base address based dwfl_report_elf_baseaddr
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Tue, 19 Mar 2013 11:19:44 +0100
- Subject: 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