This is the mail archive of the
mailing list for the binutils project.
Re: libctf: make it compile for old glibc
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
> Yes, please. Thanks.
I'll add it into the linker batch's preparatory work. (16 commits
>> > 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)