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