libctf: make it compile for old glibc

Hans-Peter Nilsson hp@bitrange.com
Thu Jul 11 13:12:00 GMT 2019


On Thu, 11 Jul 2019, Nick Alcock wrote:
> On 11 Jul 2019, Hans-Peter Nilsson stated:
> 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,

Yes, please.  Thanks.

> 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.)

Right.  If it's there the next time I step by, I'll do that.

> > (Where does the idea of a bytestap.h bswap_identity_64 come from?)
>
> The uint*_identity() macros in glibc's <endian.h>.

Ah.  (Still, there's no bswap_identity_64 to duplicate.)

> > 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).

I missed that there are CTF pieces missing from binutils, but to
test the CTF-consumer (say, objdump which I assume is complete),
you can generate CTF artificially.  It makes sense to me to do
that in the presence of a CTF producer, to test that the
generated format matches the specs.

> > 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.

But objdump should be able to decode CTF generated by outside
producers, right?

> > 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. :)

Sounds better than an editing mistake. :)  Otherwise we'd do
that for all function-like system thingies that might be macros.

brgds, H-P



More information about the Binutils mailing list