Re: sdt.h vs comdat

[Roland McGrath <roland at redhat dot com>]

> As comment #11 said: "Although this doesn't fix the general comdat
> section issue, it does fix the issue at hand ... When we find other C++
> related issues we should open a new bug."

Well, we know of multiple ways to produce different COMDAT situations that
have different problems.  AFAIK we do not yet know of any actual cases of
C++ code putting probes in the combinations of places where these would
happen.

> > As PR10512 mentions, C/C++ data declarations using __attribute__
> > ((section)) implicitly do the right thing.  You say section "foo", and
> > the compiler actually emits COMDAT section "foo" in the COMDAT group
> > of the containing function.
> 
> Modulo a bug that prevents you from doing that when you mix C and C++
> code: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091
> "Using section attribute in c and c++ function causes section type conflict"

Ah.  That is still a problem, and it breaks the C-declaration scheme just
as badly, though in a different set of cases.  IMHO the constraint this
imposes (can't have probes both in COMDAT and non-COMDAT code in the same
translation unit) is worse than the one the "discussion draft" macros
produce (can't have probes in duplicate COMDAT code that is actually
discarded at link time).  We won't really improve on the status quo without
some compiler change or other.  While fixing gcc 41091 might be easier
or more likely 

[fche:]
> The text bloat does not seem like a serious impediment.  How many
> relocs would survive upon a return to an allocated section scheme?

In any sensible scheme the maximum number of relocs required is one per
probe (that's in PIC code).  If the scheme creates PIC relocs, then it
is in fact not text bloat, but data bloat (i.e. real memory pressure,
not just locality/cache pressure).  (A 'static const' definition goes
into .data{,.relro} instead of .rodata (text) if its initializer
contains any address constants, since the dynamic relocs will require
writing at startup.)

If you have text bloat anyway, then you can use a PC-relative address
encoding and not have any dynamic relocs.  But, there is no way to
express that in the C initializer so that the compiler will be willing
to emit it (&foo - &bar is not a constant).  I had a little luck with:

  extern void probe asm(".Lxxx-.");
  static void *const anno __attribute__ ((used, section (".anno"))) = &probe;
  asm (".Lxxx: nop");

which is only 66.6% evil.  But that will make it want to make .anno a
writable section even though it won't actually generate any dynamic
relocs.  There is a 33.3% evil hack that libc uses to fake it out and
generate a section with flags of its choosing:

	__attribute__ ((used, section (".note.foo,\"\",\"note\" #")))

so the generated asm winds up:

	.section .note.foo,"","note" #,"aw",@progbits

and the # is a comment in at least 57.2% of arch's assembly syntax,
so muwahaha.  But, the whole reason we were pimping the compiler to
generate our annotations at all was that it would make that:

	.section .note.foo,"","note" #,"aw",@progbits,_Zgroupmanglation,comdat

and having the magic tokens in the comment really doesn't help our cause!

Frankly, I think it's fine to have the status quo and only make it
better when you build (and configure systemtap with, even) a newer
toolchain.  So, we could do C declarations and get the compiler to
fix its section conflict logic, and hey, even get them to add:

	__attribute__ ((used, section (".note.foo", "", "note")))

so we can specify the section flags and type in C like a civilized
person, with no monkey business.  Then we could win when we had the new
compiler.  But the only reason to use C declarations *at all* is to get
the implicit COMDAT group special sauce.  So, why not instead of relying
on the new compiler that doesn't exist yet, just rely on a new assembler
with the new feature I finished implementing yesterday?  It's so easy,
it's almost done already!

So, I know you don't care about the data bloat or the startup cost of
relocs.  But maintainers of system standard libc/libpthread builds do.
Zero relocs is going to be a requirement for what gets used in libc.

But, libc does not need COMDAT-friendliness.  People writing C++
probably don't care half as much about data bloat or startup relocs.
So there could be two versions of the scheme, with #ifdef __cplusplus.
Not that I like that at all, it's just a pain.

I've done 72.3% of the work of making my new macros silence -ansi -pedantic.
So don't push me, fella.


Thanks,
Roland