This is the mail archive of the
mailing list for the elfutils project.
Re: [PATCH v2 1/3] libdw: Add dwarf_debugaltlink function
- From: Florian Weimer <fweimer at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Thu, 10 Apr 2014 20:41:13 +0200
- Subject: Re: [PATCH v2 1/3] libdw: Add dwarf_debugaltlink function
On 04/10/2014 08:29 PM, Mark Wielaard wrote:
>>> I like the helper function, but I think it is a little more low-level
>>> than what we normally provide. We should at least (also) have a
>>> dwarf_get_alt () that returns a Dwarf *.
>> This would just return the stored Dwarf *, and not attempt to open any
> Yes. dwarf_getalt () would just return the set Dwarf *alt (or NULL when
> none was set).
Okay, I will include this in a revision of the patch.
>> We could add them at the ELF layer, but then we'd have to iterate over
>> all the ELF section headers in each of these functions. The section
>> header array in libdw avoids this. I'm also not sure where to put such
>> convenience functions.
> Yeah, I might be designing things. You are right having it in libdw and
> using the debug section array is the right thing to use. I am mostly
> concerned about the naming because I think this functionality is at a
> different level than the rest.
So what about dwarf_elf_debugaltlink or even dwarf_elf_gnu_debugaltlink
as a name? This shows the relationship to the underlying ELF data.
>> libebl? But I currently don't use that, and I
>> think some downstreams assign send-class status to it.
> libebl is strictly for internal use, not for public functions.
> The utility functions could just be part of libdw, just like the dwfl
> functions are, just with a slightly different naming convention (let the
> bike-shedding begin).
> BTW. I don't know what assigning send-class status means.
Typo for "second-class". :)
>>> I would make build_id_len the return value. Then you can return:
>>> - 0 No debugaltlink found.
>>> - > 0 Length of build_id, success.
>>> - < 0 Error.
>> Hmm, I wonder if the interface is similar enough to read(2) so that the
>> tri-state return value isn't a problem. Usually, it's problematic
>> because callers are tempted to treat the result as boolean, interpreting
>> -1 as success.
> The tri-state return value pattern is used with more libdw functions, so
> I don't think it will surprise our users. Especially not if we properly
> document it :)
Okay, I will make this change as well.
Florian Weimer / Red Hat Product Security Team