[Bug uprobes/17049] New: dtrace does not support -fPIC option anymore

[Bug uprobes/17049] New: dtrace does not support -fPIC option anymore

[bonzini at gnu dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17049

            Bug ID: 17049
           Summary: dtrace does not support -fPIC option anymore
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: uprobes
          Assignee: systemtap at sourceware dot org
          Reporter: bonzini at gnu dot org

Until recently, it was possible to use dtrace together with libtool like this:

libtool  --mode=compile --tag=CC dtrace -o trace/generated-tracers.lo \
   -G -s trace/generated-tracers.dtrace

Right now however it gives this error:

/usr/bin/dtrace invalid option -fPIC
Usage /usr/bin/dtrace [--help] [-h | -G] [-C [-I<Path>]] -s File.d [-o <File>]

Even though -fPIC is included by dtrace automatically, libtool doesn't know
this.  Would it be possible to revert the previous behavior for the sake of
compatibility?

This affects all releases of QEMU (the next one, 2.1, should have a
workaround).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug uprobes/17049] dtrace does not support -fPIC option anymore

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17049

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fche at redhat dot com

--- Comment #1 from Frank Ch. Eigler <fche at redhat dot com> ---
Paolo, what range of cc flags are we supposed to accept?
Why is the dtrace invocation wrapped by libtool?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug uprobes/17049] dtrace does not support -fPIC option anymore

[bonzini at gnu dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17049

--- Comment #2 from Paolo Bonzini <bonzini at gnu dot org> ---
It is wrapped by libtool in order to produce a .lo file that ends in a libtool
library.

libtool doesn't add any other flag than -fPIC -DPIC.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug uprobes/17049] dtrace does not support -fPIC option anymore

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17049

--- Comment #3 from Frank Ch. Eigler <fche at redhat dot com> ---
Is there any way to avoid using libtool --tag=CC, that is to stop pretending
to libtool that the dtrace program is cc-like?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug uprobes/17049] dtrace does not support -fPIC option anymore

[bonzini at gnu dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17049

--- Comment #4 from Paolo Bonzini <bonzini at gnu dot org> ---
Yeah, one could add a new tag to libtool but that is somewhat harder to do
(slow releases, slow updates in distros, etc.).

On the other hand, is there a reason why dtrace adds -fPIC automatically? 
Couldn't it take it from the command line?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug uprobes/17049] dtrace does not support -fPIC option anymore

[scox at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17049

Stan Cox <scox at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |scox at redhat dot com

--- Comment #5 from Stan Cox <scox at redhat dot com> ---
Previously, unrecognized options were passed through without complaint in case
a Makefile used an unsupported dtrace option.  Perusing Makefiles, not
exhaustive mind you, the only unsupported options I saw were -32 and -64 so I
recognized those and complain about any other unrecognized options; just in
case someone says dtrace -jump-in-the-lake  By the way, I don't see -fPIC on
the list of supported dtrace options below. Is the -fpic usage upstream and
does dtrace  just pass it through?  

-a Claim anonymous tracing state and display the traced data.
-A Generate driver.
-b Set principal trace buffer size.
-c Run the specified command cmd and exit upon its completion.
-C Run the C preprocessor cpp(1) over D programs before compiling them.
-D Define the specified name when invoking cpp(1) (enabled using the -C
option).
-e Exit after compiling any requests and consuming anonymous tracing state (-a
option) but prior to enabling any probes.
-f Specify function name to trace or list (-l option).
-F Coalesce trace output by identifying function entry and return.
-G Generate an ELF file containing an embedded DTrace program.
-H Print the pathnames of included files when invoking cpp(1) (enabled using
the -C option).
-i Specify probe identifier to trace or list (-l option).
-I Add the specified directory path to the search path for #include files when
invoking cpp(1) (enabled using the -C option).
-l List probes instead of enabling them.
-L Add the specified directory path to the search path for DTrace libraries.
-m Specify module name to trace or list (-l option).
-n Specify probe name to trace or list (-l option).
-o Specify the output file for the -A , -G, and -l options, or for the traced
data.
-p Grab the specified process-ID pid, cache its symbol tables, and exit upon
its completion.
-P Specify provider name to trace or list (-l option).
-q Set quiet mode.
-s Compile the specified D program source file.
-S Show D compiler intermediate code.
-U Undefine the specified name when invoking cpp(1) (enabled using the -C
option).
-v Set verbose mode.
-V Report the highest D programming interface version supported by dtrace.
-w Permit destructive actions in D programs specified using the -s, -P, -m, -f,
-n, or -i options.
-x Enable or modify a DTrace runtime option or D compiler option.
-X Specify the degree of conformance to the ISO C standard that should be
selected when invoking cpp(1) (enabled using the -C option).
-Z Permit probe descriptions that match zero probes.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug uprobes/17049] dtrace does not support -fPIC option anymore

[bonzini at gnu dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17049

--- Comment #6 from Paolo Bonzini <bonzini at gnu dot org> ---
-fPIC is a compiler option, not a dtrace option.

I doubt anyone tested QEMU's usage of dtrace on anything but systemtap.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug uprobes/17049] dtrace does not support -fPIC option anymore

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17049

--- Comment #7 from Frank Ch. Eigler <fche at redhat dot com> ---
Paolo, my guess is that it was just an accident that libtool-wrapping
/usr/bin/dtrace this way ever worked.  Can you change the makefile to
hard-code  dtrace -o FOO.lo  etc.?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug uprobes/17049] dtrace does not support -fPIC option anymore

[bonzini at gnu dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17049

Paolo Bonzini <bonzini at gnu dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #8 from Paolo Bonzini <bonzini at gnu dot org> ---
No, I cannot...  The .lo file is something like this

# trace/generated-tracers.lo - a libtool object file
# Generated by libtool (GNU libtool) 2.4.2
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# Name of the PIC object.
pic_object='.libs/generated-tracers.o'

# Name of the non-PIC object
non_pic_object='generated-tracers.o'

The format and location of the objects is internal to libtool.  Also, QEMU uses
a pre-installed libtool (because QEMU is not autoconfiscated) so I cannot add a
special-purpose DTRACE tag.

Note that this will be mostly a problem with downstream distributions, since
upstream we're dropping this usage anyway for unrelated reasons (we do not need
to put generated-tracers.o in a library anymore).  I guess one could hack the
dtrace script around in downstream systemtap.

Thanks for the discussion!

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug uprobes/17049] dtrace does not support -fPIC option anymore

[scox at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17049

Stan Cox <scox at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

--- Comment #9 from Stan Cox <scox at redhat dot com> ---
commit: c486eff3f809

Add -fpic -fPIC to the list of accepted but ignored dtrace options.

-- 
You are receiving this mail because:
You are the assignee for the bug.