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: libelf gelf_newehdr and gelf_newphdr return types


On 12/ 2/16 02:42 AM, Mark Wielaard wrote:
> Hi,
>
> Someone was porting elfutils libelf to Windows64 and noticed that the
> return types of gelf_newehdr and gelf_newphdr (unsigned long int) is not
> appropriate on that platform. It uses the LLP64 data model where int and
> long are both 32bits, while pointers are 64bits. Instead of the more
> common LP64 model where both long and pointer are 64bits. This obviously
> breaks that interface.
>
> I couldn't find the history behind this return type. Both elfutils and
> solaris libelf share the same return type, but some other libelf
> implementations, like the freebsd one, return a void *. Which does make
> more sense IMHO. Does someone remember the background?
>
> I have been pondering just changing the return type to void *, which
> should be abi compatible on any platform that elfutils currently
> supports. But it might cause some compiler warnings about needed or
> unneeded casts when existing code relies on the the return type being an
> integral type. So an alternative would be to make the functions return
> an uintptr_t, which should work in all data models.
>
> Any opinions if this is something to clarify/fix across
> implementations/platforms supporting an libelf implementation?
>
> Thanks,
>
> Mark
>


Hi Mark,

    I'm currently searching code to see what the impacts are,
but I suspect that there are none, and that we should follow
FreeBSD's lead. They've done us a service by already testing
out the viability.

The reason for using unsigned long was undoubtedly so that
pre-K&R C compilers can compile the code. gelf was invented
at a time in history where ansi C was still pretty new, and
not everyone was using it. 'unsigned long' was the pre-ansi
idiom for "generic pointer" that could be used in either mode.

All of the code I've found in Solaris using these functions so
far, and there is very little, treat the return value as a
pointer, and even compare it to NULL, so switching to 'void *'
would be transparent and binary compatible.

I'll follow up to this as soon as I'm done digging. In the meantime,
might I suggest that you make this change in a test environment,
do a 'make world', and see if you hit any issues?

Thanks.

- Ali

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