libctf: make it compile for old glibc

[Nick Alcock]

On 11 Jul 2019, Hans-Peter Nilsson spake thusly:

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

I'll add it into the linker batch's preparatory work. (16 commits
already...)

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

Yes.. but the spec hasn't been written yet either (though I'll probably
do that before I start work on the big pile of compactness increases
which will be format v4.)

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

Yes, but right now there are only two: libctf and GCC. So it's hard to
test it against a third producer, when no third exists :) though I'd
agree that when a third *does* exist, we should generate some CTF with
it and make sure that at the very least we can read it in with libctf.

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

Doesn't everyone do that sort of thing in macro definitions? I know I
feel guilty whenever I forget.

-- 
NULL && (void)