libctf: make it compile for old glibc
Sun Jul 14 23:18:00 GMT 2019
On Sun, 14 Jul 2019, Nick Alcock wrote:
> On 11 Jul 2019, Hans-Peter Nilsson spake thusly:
> > 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.
The posted links made me think CTF was in heavy use somewhere in
BSD-land and for some Solaris thingy since years already (dtrace)?
Is it, but for an incompatible version? If so, supporting the
pre-existing versions (at least reading them) will probably be
requested sooner rather than later.
> >> > 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.
Not really; this is sufficiently different to the parentheses in
e.g. "#define SQUARE(x) ((x) * (x))" which should be in the
memory of everyones fingertips.
Writing it as "#define htole64(x) bswap_64 (x)" should be
sufficient; you should not worry about definitions (system
headers, glibc) missing to parenthesize any macro arguments.
A "#define htole64(x) bswap_64 ((x))" (without a known buggy
version pointed out in a comment above the definition) just
causes confusion for the reader, QED. I should add that's IMHO,
but I've never seen that "distrust" in use of macros around
here. Even if so, it's missing a set of parentheses. ;-)
More information about the Binutils