Re: systemtap multiple objs linking question

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

> >> You could also opt to disable the sempahore mechanism, which may not
> >> buy you anything on stap.  I believe on newer systemtap, it defaults
> >> disabled, thus not making reference to *_*_semaphore variables.
> 
> How do I do this?  It seems like that might be the road to go,

Yeah, I misremembered ... the /usr/bin/dtrace wrapper script
that processes .d files hard-codes this in its header output:
   #define _SDT_HAS_SEMAPHORES 1
   #include <sys/sdt.h>

So the way around this could be to

   #include <sys/sdt.h>
   #include "dtrace-generated-trace-header.h"

in that order in the instrumented C code.  That way, the initial
(#undef) value of that macro will be used to define <sys/sdt.h>
contents, and by the time the dtrace-generated-trace-header.h
re-#includes <sys/sdt.h>, it will be too late: FOO_ENABLED() will be
hard-coded at 1, and no semaphores will be compiled in.

... but we really ought to have a better method for this.


> attached is the latest build.log, showing the _sema.o being listed in
> the call to the linker...

Try to arrange it to show up before the -Wl,--end-group, perhaps.

- FChE