Re: libctf: make it compile for old glibc

[Nick Alcock <nick dot alcock at oracle dot com>]

On 11 Jul 2019, Hans-Peter Nilsson stated:

> With a glibc before 2.9 (such as 2.8), there's <endian.h> but no
> htole64 or le64toh, so you get, compiling binutils for any target:

Wow, such ancient glibcs are still in use? Aren't they a crawling
nightmare of security holes?

> libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes \
> -Wshadow -Werror -I/x/binutils/../zlib -g -O2 -o objdump \
> objdump.o dwarf.o prdbg.o rddbg.o debug.o stabs.o rdcoff.o \
> bucomm.o version.o filemode.o elfcomm.o  ../opcodes/.libs/libopcodes.a \
> ../libctf/libctf.a ../bfd/.libs/libbfd.a -L/x/obj/b/zlib -lz ../libiberty/libiberty.a -ldl
> ../libctf/libctf.a(ctf-archive.o): In function `ctf_archive_raw_iter_internal':
> /x/src/libctf/ctf-archive.c:543: undefined reference to `le64toh'
> /x/src/libctf/ctf-archive.c:550: undefined reference to `le64toh'
> /x/src/libctf/ctf-archive.c:551: undefined reference to `le64toh'
> /x/src/libctf/ctf-archive.c:551: undefined reference to `le64toh'
> /x/src/libctf/ctf-archive.c:554: undefined reference to `le64toh'
> ../libctf/libctf.a(ctf-archive.o):/x/src/libctf/ctf-archive.c:545: more undefined references to `le64toh' follow
> (etc)
>
> Also, I see no bswap_identity_64 *anywhere* except in libctf/swap.h
> (including current glibc) and I don't think calling an "identity"-
> function is better than just plain "#define foo(x) (x)" anyway.

We clearly need to check for the existence of htole64 etc, either at
configure time or in the configure script as you suggest.

I have a big pile of stuff built up to be pushed soon (ctf linking work,
mostly in libctf but a bit in ld): I can add your commit to it if you
like, or you can push yours independently. I'm happy with it. (But you
can probably go further and drop the bswap_identity stuff from
libctf/swap.h, as well.)

> (Where does the idea of a bytestap.h bswap_identity_64 come from?)

The uint*_identity() macros in glibc's <endian.h>.

> Speaking of that, I should mention that I instrumented the condition
> to observe that the WORDS_BIGENDIAN case passes too for a presumed
> big-endian target and glibc-2.8: there is a bswap_64 present for that
> version.  Curiously, no test-case regressed with that instrumentation.

That would be because the testcases can't really be written until the
linker is done :) (and even then, they'll get skipped if you don't have
a CTF-generating compiler).

> For the record, constructing binary blobs using text source to run
> tests on, can be done by linking to --oformat binary (with most ELF
> targets), but I guess that's seen as unnecessary roundabout perhaps
> checking in binary files in the test-suite would be ok these days.

I was planning to just compile test C programs using a suitable
CTF-generating compiler, do things that need testing (like linking and
deduplication) then objdump/readelf it and diff the results. If the user
doesn't have a suitable compiler, it doesn't matter whether CTF works or
not because the CTF code in binutils won't have anything to work on
anyway: the compiler is the ultimate upstream source of all the CTF
binutils works with, after all.

Testing cross-endianness is the one case where we might need more --
probably, as you suggest, something explicitly checked in.

> Anyway, is this ok to commit or do I have to also check for
> htole64 being a function?

If we define a macro with the same name, it will supersede it in any
case: so I don't think a functional htole64() will cause us any
problems.

> BTW, what's up with the ((x)) seen in the context?  Worrying about
> buggy library implementations not parenthesizing arguments?

Pure paranoia, yes :) it's easier to add one layer of brackets than
worry about every use of the macros. Always-parenthesised args are just
safer. :)

-- 
NULL && (void)