This is the mail archive of the 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 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
>> files?
> 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

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