[Mono-dev] Mono dtrace provider?

[Andreas Färber]

Hey,

Am 13.01.2008 um 19:12 schrieb Miguel de Icaza:

>
>> Mono however uses libtool+automake for building: First, there seem to
>> be PIC and non-PIC .o files generated; then most .o files are  
>> compiled
>> into .a archives; and finally, all these .o files are handled
>> automagically by libtool/automake/whatever so it's difficult to add
>> such manual build steps.
>
> PIC files are only used when you embed Mono into a third party
> application (when you use -lmono).   The static case is what Mono uses
> if you invoke it as a runtime from the command line ("mono app.exe")

Both were being compiled here, and if I don't link this stub I get an  
unresolved symbol error. This only goes away if I pass the .o file  
(mini.o) to dtrace -G too, and then suddenly the generated .o file  
(mono-dtrace.o) is no longer readable by gobjdump though `file' still  
identifies it as ELF object file. Some ELF headers are supposedly  
being added/modified by dtrace, but documentation is very vague on  
this, and same thing happens for a test app where DTrace works  
afterwards.

I'm testing this btw with /usr/sbin/dtrace -P mono'$target' -c 'mono/ 
mini/mono ../test.exe' (as root), and "doesn't work" refers to:

dtrace: invalid probe specifier mono$target: probe description  
mono12345::: does not match any probes

whereas it's supposed to write:

dtrace: description 'mono$target' matched 1 probe


>> I thought data/ would be an obvious choice for the .d file, and chose
>> mono/utils for the generated header and object file but the object
>> file seems to depend on all object files with the probes, here mini.o
>
> Hand written information can go into the data directory;   Source code
> generated by a tool should be generated at compile time.

Okay, sure, that's what I already do. Is mono/utils a suitable place  
for such a compile-time generated header, or should it go directly  
into mono/mini where the existing trace.(h|c) files live? It just  
needs to be built before we use it anywhere, obviously, and dtrace -G  
apparently needs the object files where the probes are used.


Today I figured out that my mono-dtrace.o file was not being archived  
into libmono-static.a by ar. I fixed this with a severe hack, manually  
generating a .lo file as input for _LIBADD, see attached. Results are  
no better though. Configuring --with-static-mono=no made no difference  
either.

I've already checked with a hello world program that it's not related  
to compiling with gcc or with -g -O2 flags.

It seems virtually no other project using DTrace is using libtool ...  
the ones I'm aware of are Mozilla (autoconf only), Ruby (autoconf  
only), Perl (shell-script-generated Makefile); for Apache and PHP  
people built it as module/extension library, avoiding their project's  
build system. The only DTrace provider apparently using libtool is  
this one:
http://hg.tangent.org/skeleton-mysql-engine/
Open MPI, using libtool, was reported to be working on DTrace support  
(in a message to the author of the above) but I see nothing in 1.2.5  
or SVN HEAD.

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtrace-hack2.diff
Type: application/octet-stream
Size: 3077 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080114/36f93251/attachment.obj 
-------------- next part --------------