dtrace/-DDEBUGGING builds fail on multiple platforms

[p5pRT]

Migrated from rt.perl.org#127543 (status was 'open')

Searchable as RT127543$

[p5pRT]

From @tonycoz

Recently Solaris builds with both -DDEBUGGING and -Dusedtrace have started failing
to build.

/opt/solarisstudio12.3/bin/cc -o libperl.so -G -L/usr/lib -L/usr/ccs/lib -L/opt/solarisstudio12.3/prod/lib -L/lib -L/usr/gnu/lib op.o perl.o gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o time64.o perldtrace.o DynaLoader.o -lpthread -lsocket -lnsl -ldl -lm -lc
/opt/solarisstudio12.3/bin/cc -o perl -L/usr/lib -L/usr/ccs/lib -L/opt/solarisstudio12.3/prod/lib -L/lib -L/usr/gnu/lib -R /opt/lib/perl5/5.23.8/i86pc-solaris/CORE perlmain.o libperl.so `cat ext.libs` -lpthread -lsocket -lnsl -ldl -lm -lc
Undefined first referenced
symbol in file
__dtrace_perl___sub__entry perlmain.o
__dtraceenabled_perl___sub__return perlmain.o
__dtraceenabled_perl___sub__entry perlmain.o
__dtrace_perl___sub__return perlmain.o
ld​: fatal​: symbol referencing errors. No output written to perl
gmake​: *** [perl] Error 2

[p5pRT]

From @tonycoz

On Sun Feb 14 18​:26​:50 2016, tonyc wrote​:

Recently Solaris builds with both -DDEBUGGING and -Dusedtrace have
started failing
to build.

/opt/solarisstudio12.3/bin/cc -o libperl.so -G -L/usr/lib
-L/usr/ccs/lib -L/opt/solarisstudio12.3/prod/lib -L/lib -L/usr/gnu/lib
op.o perl.o gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o
reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o
scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o
universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o
pp_pack.o pp_sort.o caretx.o dquote.o time64.o perldtrace.o
DynaLoader.o -lpthread -lsocket -lnsl -ldl -lm -lc
/opt/solarisstudio12.3/bin/cc -o perl -L/usr/lib -L/usr/ccs/lib
-L/opt/solarisstudio12.3/prod/lib -L/lib -L/usr/gnu/lib -R
/opt/lib/perl5/5.23.8/i86pc-solaris/CORE perlmain.o libperl.so `cat
ext.libs` -lpthread -lsocket -lnsl -ldl -lm -lc
Undefined first referenced
symbol in file
__dtrace_perl___sub__entry perlmain.o
__dtraceenabled_perl___sub__return perlmain.o
__dtraceenabled_perl___sub__entry perlmain.o
__dtrace_perl___sub__return perlmain.o
ld​: fatal​: symbol referencing errors. No output written to perl
gmake​: *** [perl] Error 2

This seems to have been introduced by​:

commit a73d881
Author​: David Mitchell <davem@​iabyn.com>
Date​: Wed Dec 30 12​:33​:48 2015 +0000

  convert CX_PUSHSUB/POPSUB to inline fns
 
  Replace CX_PUSHSUB() with cx_pushsub() etc.
 
  No functional changes.

Inline Patch

diff --git a/cop.h b/cop.h
index 3a7afb5..d7ae2d6 100644
--- a/cop.h
+++ b/cop.h
@@ -595,20 +595,6 @@ struct block_format {
  * The context frame holds a reference to the CV so that it can't be
  * freed while we're executing it */

(tested by building both a73d881 and it's parent.)

I don't see why this only happens in -DDEBUGGING builds.

Adding the fairly obvious change to Makefile.SH​:

Inline Patch

diff --git a/Makefile.SH b/Makefile.SH
index 2278f9f..4377d10 100755
--- a/Makefile.SH
+++ b/Makefile.SH
@@ -841,8 +841,8 @@ mydtrace.h: $(DTRACE_H)
        case "$dtrace_o" in
        ?*)
                $spitshell >>$Makefile <<'!NO!SUBS!'
-$(DTRACE_O): perldtrace.d $(ndt_obj)
-       $(DTRACE) -G -s perldtrace.d -o $(DTRACE_O) $(ndt_obj)
+$(DTRACE_O): perldtrace.d $(ndt_obj) perlmain$(OBJ_EXT)
+       $(DTRACE) -G -s perldtrace.d -o $(DTRACE_O) $(ndt_obj) perlmain$(OBJ_EXT
 
 $(MINIDTRACE_O): perldtrace.d $(minindt_obj) perlmini$(OBJ_EXT)
        $(DTRACE) -G -s perldtrace.d -o $(MINIDTRACE_O) $(minindt_obj) perlmini$

results in a dynamic linking error when perl (as opposed to miniperl) is first run:

LD_LIBRARY_PATH=/home/tony/dev/perl/git/perl ./perl -Ilib -f pod/buildtoc -q
ld.so.1​: perl​: fatal​: relocation error​: file /home/tony/dev/perl/git/perl/libperl.so​: symbol $dtrace3181974.S_cx_pushsub​: referenced symbol not found
gmake​: *** [pod/perltoc.pod] Killed

so I suspect the dtrace calls will need to hoisted out of the inline functions into wrapper macros and we need to *not* apply the Makefile.SH change above.

This is similar to inline.h problems we've had in the past, where symbols referenced by unused inline functions have still caused references to those symbols.

Tony

[p5pRT]

From @tonycoz

On Sun Feb 14 21​:00​:17 2016, tonyc wrote​:

I don't see why this only happens in -DDEBUGGING builds.

Possibly because the assertions make the code large enough that the compiler doesn't want to inline them anymore.

Tony

[p5pRT]

From @iabyn

On Sun, Feb 14, 2016 at 09​:00​:17PM -0800, Tony Cook via RT wrote​:

On Sun Feb 14 18​:26​:50 2016, tonyc wrote​:

Recently Solaris builds with both -DDEBUGGING and -Dusedtrace have
started failing
to build.
[snip]
This seems to have been introduced by​:

commit a73d881
Author​: David Mitchell <davem@​iabyn.com>
Date​: Wed Dec 30 12​:33​:48 2015 +0000

convert CX\_PUSHSUB/POPSUB to inline fns

Replace CX\_PUSHSUB\(\) with cx\_pushsub\(\) etc\.

so I suspect the dtrace calls will need to hoisted out of the inline
functions into wrapper macros and we need to *not* apply the Makefile.SH
change above.

Well I don't understand why the static inlining is tripping up Solaris,
but making the dtrace probe macros into functions has been on my todo list
for a while now, so I've gone ahead and done it, as smoke-me/davem/dtrace.

Can you let me know if it fixes the Solaris issue?

It appears that t/run/dtrace.t doesn't play well on Linux, since the
SystemTap system has only a superficial compatibility with DTrace. So I
haven't been able to check whether my changes break t/run/dtrace.t.

If I've read things right, t/run/dtrace.t would have to change calling
/usr/bin/dtrace into calling /usr/bin/stap and/or /usr/bin/staprun and
mess around loading kernel modules and stuff. At which point I quietly
stopped digging.

--
I thought I was wrong once, but I was mistaken.

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @iabyn

On Mon, Feb 15, 2016 at 03​:33​:38PM +0000, Dave Mitchell wrote​:

Well I don't understand why the static inlining is tripping up Solaris,
but making the dtrace probe macros into functions has been on my todo list
for a while now, so I've gone ahead and done it, as smoke-me/davem/dtrace.

and now as smoke-me/davem/dtrace2, with added makedef.pl goodness to keep
win32 happy.

--
"Do not dabble in paradox, Edward, it puts you in danger of fortuitous wit."
  -- Lady Croom, "Arcadia"

[p5pRT]

From @tonycoz

On Mon, Feb 15, 2016 at 04​:45​:35PM +0000, Dave Mitchell wrote​:

On Mon, Feb 15, 2016 at 03​:33​:38PM +0000, Dave Mitchell wrote​:

Well I don't understand why the static inlining is tripping up Solaris,
but making the dtrace probe macros into functions has been on my todo list
for a while now, so I've gone ahead and done it, as smoke-me/davem/dtrace.

and now as smoke-me/davem/dtrace2, with added makedef.pl goodness to keep
win32 happy.

Still a problem​:

Undefined first referenced
symbol in file
__dtraceenabled_perl___sub__entry perlmain.o
ld​: fatal​: symbol referencing errors. No output written to perl

Caused by PERL_SUB_ENTRY_ENABLED().

Tony

[p5pRT]

From @tonycoz

On Mon Feb 15 14​:46​:05 2016, tonyc wrote​:

Still a problem​:

Undefined first referenced
symbol in file
__dtraceenabled_perl___sub__entry perlmain.o
ld​: fatal​: symbol referencing errors. No output written to perl

Caused by PERL_SUB_ENTRY_ENABLED().

The attached fixes it.

Tony

[p5pRT]

From @tonycoz

0001-move-the-dtrace-macro-calls-out-of-cx_-push-pop-sub.patch

From b7e538a86b1d07cdcf264cec577664ebb305491d Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Tue, 16 Feb 2016 16:42:09 +1100
Subject: move the dtrace macro calls out of cx_(push|pop)sub()

This avoids references to the internal dtrace symbols by
perlmain when cx_pushsub or cx_popsub are complex enough that
the compiler turns them into static functions (which happens with
-DDEBUGGING.)
---
 cop.h     |   12 +++++++++---
 inline.h  |    3 ---
 pp_ctl.c  |    6 +++---
 pp_hot.c  |    4 ++--
 pp_sort.c |    4 ++--
 5 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/cop.h b/cop.h
index dfb4a00..8fb96cb 100644
--- a/cop.h
+++ b/cop.h
@@ -590,11 +590,17 @@ struct block_format {
 #  define CX_POP(cx) cxstack_ix--;
 #endif
 
+#ifdef PERL_CORE
+
+#define CX_PUSHSUB(cx, cv, retop, hasargs) \
+    PERL_DTRACE_PROBE_ENTRY(cv);           \
+    cx_pushsub(cx, cv, retop, hasargs);
 
-/* base for the next two macros. Don't use directly.
- * The context frame holds a reference to the CV so that it can't be
- * freed while we're executing it */
+#define CX_POPSUB(cx)                           \
+    PERL_DTRACE_PROBE_RETURN((cx)->blk_sub.cv); \
+    cx_popsub(cx);    
 
+#endif
 
 #define CX_PUSHSUB_GET_LVALUE_MASK(func) \
 	/* If the context is indeterminate, then only the lvalue */	\
diff --git a/inline.h b/inline.h
index 1e657cc..8916f44 100644
--- a/inline.h
+++ b/inline.h
@@ -480,7 +480,6 @@ S_cx_pushsub(pTHX_ PERL_CONTEXT *cx, CV *cv, OP *retop, bool hasargs)
 
     PERL_ARGS_ASSERT_CX_PUSHSUB;
 
-    PERL_DTRACE_PROBE_ENTRY(cv);
     cx->blk_sub.cv = cv;
     cx->blk_sub.olddepth = CvDEPTH(cv);
     cx->blk_sub.prevcomppad = PL_comppad;
@@ -540,8 +539,6 @@ S_cx_popsub(pTHX_ PERL_CONTEXT *cx)
     PERL_ARGS_ASSERT_CX_POPSUB;
     assert(CxTYPE(cx) == CXt_SUB);
 
-    PERL_DTRACE_PROBE_RETURN(cx->blk_sub.cv);
-
     if (CxHASARGS(cx))
         cx_popsub_args(cx);
     cx_popsub_common(cx);
diff --git a/pp_ctl.c b/pp_ctl.c
index 7b31bbb..f6cdc8c 100644
--- a/pp_ctl.c
+++ b/pp_ctl.c
@@ -1531,7 +1531,7 @@ Perl_dounwind(pTHX_ I32 cxix)
 	    CX_POPSUBST(cx);
 	    break;
 	case CXt_SUB:
-	    cx_popsub(cx);
+	    CX_POPSUB(cx);
 	    break;
 	case CXt_EVAL:
 	    cx_popeval(cx);
@@ -2012,7 +2012,7 @@ PP(pp_dbstate)
 	}
 	else {
 	    cx = cx_pushblock(CXt_SUB, gimme, SP, PL_savestack_ix);
-	    cx_pushsub(cx, cv, PL_op->op_next, 0);
+	    CX_PUSHSUB(cx, cv, PL_op->op_next, 0);
             /* OP_DBSTATE's op_private holds hint bits rather than
              * the lvalue-ish flags seen in OP_ENTERSUB. So cancel
              * any CxLVAL() flags that have now been mis-calculated */
@@ -2349,7 +2349,7 @@ PP(pp_leavesublv)
     }
 
     CX_LEAVE_SCOPE(cx);
-    cx_popsub(cx);	/* Stack values are safe: release CV and @_ ... */
+    CX_POPSUB(cx);	/* Stack values are safe: release CV and @_ ... */
     cx_popblock(cx);
     retop =  cx->blk_sub.retop;
     CX_POP(cx);
diff --git a/pp_hot.c b/pp_hot.c
index 6a280ab..33230f6 100644
--- a/pp_hot.c
+++ b/pp_hot.c
@@ -3647,7 +3647,7 @@ PP(pp_leavesub)
         leave_adjust_stacks(oldsp, oldsp, gimme, 0);
 
     CX_LEAVE_SCOPE(cx);
-    cx_popsub(cx);	/* Stack values are safe: release CV and @_ ... */
+    CX_POPSUB(cx);	/* Stack values are safe: release CV and @_ ... */
     cx_popblock(cx);
     retop = cx->blk_sub.retop;
     CX_POP(cx);
@@ -3863,7 +3863,7 @@ PP(pp_entersub)
         gimme = GIMME_V;
 	cx = cx_pushblock(CXt_SUB, gimme, MARK, old_savestack_ix);
         hasargs = cBOOL(PL_op->op_flags & OPf_STACKED);
-	cx_pushsub(cx, cv, PL_op->op_next, hasargs);
+	CX_PUSHSUB(cx, cv, PL_op->op_next, hasargs);
 
 	padlist = CvPADLIST(cv);
 	if (UNLIKELY((depth = ++CvDEPTH(cv)) >= 2))
diff --git a/pp_sort.c b/pp_sort.c
index c91aab0..3f0b756 100644
--- a/pp_sort.c
+++ b/pp_sort.c
@@ -1671,7 +1671,7 @@ PP(pp_sort)
 	    cx = cx_pushblock(CXt_NULL, gimme, PL_stack_base, old_savestack_ix);
 	    if (!(flags & OPf_SPECIAL)) {
 		cx->cx_type = CXt_SUB|CXp_MULTICALL;
-		cx_pushsub(cx, cv, NULL, hasargs);
+		CX_PUSHSUB(cx, cv, NULL, hasargs);
 		if (!is_xsub) {
 		    PADLIST * const padlist = CvPADLIST(cv);
 
@@ -1703,7 +1703,7 @@ PP(pp_sort)
             CX_LEAVE_SCOPE(cx);
 	    if (!(flags & OPf_SPECIAL)) {
                 assert(CxTYPE(cx) == CXt_SUB);
-                cx_popsub(cx);
+                CX_POPSUB(cx);
 	    }
             else
                 assert(CxTYPE(cx) == CXt_NULL);
-- 
1.7.9.2

[p5pRT]

From @iabyn

On Mon, Feb 15, 2016 at 09​:49​:00PM -0800, Tony Cook via RT wrote​:

On Mon Feb 15 14​:46​:05 2016, tonyc wrote​:

Still a problem​:

Undefined first referenced
symbol in file
__dtraceenabled_perl___sub__entry perlmain.o
ld​: fatal​: symbol referencing errors. No output written to perl

Caused by PERL_SUB_ENTRY_ENABLED().

The attached fixes it.

I want to avoid replacing cx_pushsub etc with wrapper macros if at all
possible. The just-pushed smoke-me/davem/dtrace3 instead includes
(under -Dusedtrace) a small function that contains PERL_DTRACE_PROBE_ENTRY
and _RETURN, in the hope that it will force Solaris to link in the
necessary symbols.

--
Nothing ventured, nothing lost.

[p5pRT]

From @tonycoz

On Tue, Feb 16, 2016 at 12​:39​:30AM -0800, Dave Mitchell via RT wrote​:

On Mon, Feb 15, 2016 at 09​:49​:00PM -0800, Tony Cook via RT wrote​:

On Mon Feb 15 14​:46​:05 2016, tonyc wrote​:

Still a problem​:

Undefined first referenced
symbol in file
__dtraceenabled_perl___sub__entry perlmain.o
ld​: fatal​: symbol referencing errors. No output written to perl

Caused by PERL_SUB_ENTRY_ENABLED().

The attached fixes it.

I want to avoid replacing cx_pushsub etc with wrapper macros if at all
possible. The just-pushed smoke-me/davem/dtrace3 instead includes
(under -Dusedtrace) a small function that contains PERL_DTRACE_PROBE_ENTRY
and _RETURN, in the hope that it will force Solaris to link in the
necessary symbols.

That didn't help.

The way dtrace linking works is strange.

Each object is compiled, just before we link libperl dtrace is run on
all of the objects to do some sort of translation*​:

tony@​nereid​:~/dev/perl/git/perl$ rm op.o
tony@​nereid​:~/dev/perl/git/perl$ make op.o
make​: Warning​: Both `makefile' and `Makefile' exist
/opt/solarisstudio12.3/bin/cc -c -DPERL_CORE -DDEBUGGING -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV -O -g -KPIC op.c
"inline.h", line 377​: warning​: statement not reached
"op.c", line 10497​: warning​: statement not reached
"op.c", line 11143​: warning​: statement not reached
"op.c", line 11572​: warning​: statement not reached
"op.c", line 12570​: warning​: statement not reached
tony@​nereid​:~/dev/perl/git/perl$ ls -l op.o
-rw-r--r-- 1 tony staff 492048 Feb 17 09​:26 op.o
tony@​nereid​:~/dev/perl/git/perl$ nm op.o | grep dtrace
[170] | 0| 0|FUNC |GLOB |0 |UNDEF |Perl_dtrace_probe_call
[169] | 0| 0|FUNC |GLOB |0 |UNDEF |__dtraceenabled_perl___sub__entry
... wait a little ...
tony@​nereid​:~/dev/perl/git/perl$ date
Wed Feb 17 09​:29​:21 EST 2016
tony@​nereid​:~/dev/perl/git/perl$ gmake
...
/usr/sbin/dtrace -G -s perldtrace.d -o perldtrace.o op.o perl.o gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o time64.o
LD_LIBRARY_PATH=/home/tony/dev/perl/git/perl ./miniperl -Ilib make_ext.pl DynaLoader.o MAKE="gmake" LIBPERL_A=libperl.so LINKTYPE=static
gmake[1]​: Entering directory `/home/tony/dev/perl/git/perl/ext/DynaLoader'
gmake[1]​: Leaving directory `/home/tony/dev/perl/git/perl/ext/DynaLoader'
rm -f libperl.so
/opt/solarisstudio12.3/bin/cc -o libperl.so -G -L/usr/lib -L/usr/ccs/lib -L/opt/solarisstudio12.3/prod/lib -L/lib -L/usr/gnu/lib op.o perl.o gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o time64.o perldtrace.o DynaLoader.o -lpthread -lsocket -lnsl -ldl -lm -lc
/opt/solarisstudio12.3/bin/cc -o perl -L/usr/lib -L/usr/ccs/lib -L/opt/solarisstudio12.3/prod/lib -L/lib -L/usr/gnu/lib -R /opt/lib/perl5/5.23.8/i86pc-solaris/CORE perlmain.o libperl.so `cat ext.libs` -lpthread -lsocket -lnsl -ldl -lm -lc
Undefined first referenced
symbol in file
__dtraceenabled_perl___sub__entry perlmain.o
ld​: fatal​: symbol referencing errors. No output written to perl
gmake​: *** [perl] Error 2
tony@​nereid​:~/dev/perl/git/perl$ ls -l op.o
-rw-r--r-- 1 tony staff 492144 Feb 17 09​:30 op.o
tony@​nereid​:~/dev/perl/git/perl$ nm op.o | grep dtrace
[578] | 10816| 611|FUNC |GLOB |6 |2 |$dtrace3179801.S_cx_popsub
[577] | 9984| 302|FUNC |GLOB |6 |2 |$dtrace3179801.S_cx_pushsub
[170] | 0| 0|FUNC |GLOB |0 |UNDEF |Perl_dtrace_probe_call
[169] | 0| 0|FUNC |GLOB |0 |IGNORE |__dtraceenabled_perl___sub-entry
tony@​nereid​:~/dev/perl/git/perl$ git status
# On branch davem/dtrace3
nothing to commit (working directory clean)

Now since perlmain isn't linked into libperl.so we don't perform that
translation on perlmain, (I tried adding it earlier, the results can
be seen earlier in the thread,) so the references that are generated
in perlmain.o don't get that dtrace "magic" and fail to link.

Note that dtrace on Solaris, OS X, FreeBSD and the emulation done by
SystemTap all seem to use different mechanisms - they each like to
fail to link (or fail to work) in their own unique ways.

The only way I can see to avoid references to those dtrace symbols is
to make sure they aren't referenced in the perlmain compilation unit,
whether in an inline function (which appears to be made into a static
function here) or not.

Another option​: instead of creating CX_PUSHSUB() and CX_POPSUB()
macros would be to inline the dtrace macro calls, but that could be
error-prone for future changes.

Let me know if you want access to my Solaris VM for testing.

Tony

* I don't know the details of the translation

[p5pRT]

From @iabyn

On Wed, Feb 17, 2016 at 09​:49​:31AM +1100, Tony Cook wrote​:

The only way I can see to avoid references to those dtrace symbols is
to make sure they aren't referenced in the perlmain compilation unit,
whether in an inline function (which appears to be made into a static
function here) or not.

Would it be as simple as wrapping the cx_foo definitions in inline.h with
this?

  #ifndef PERL_IN_MINIPERLMAIN_C

Or are we likely to ru into similar problems when other people try to
embed perl.so in another application?

Let me know if you want access to my Solaris VM for testing.

Perhaps that would be best, thanks.
It would be handy to know what command-line, env etc you're using to
build perl on it.

--
Spock (or Data) is fired from his high-ranking position for not being able
to understand the most basic nuances of about one in three sentences that
anyone says to him.
  -- Things That Never Happen in "Star Trek" #19

[p5pRT]

From @tonycoz

On Wed, Feb 17, 2016 at 08​:10​:49AM -0800, Dave Mitchell via RT wrote​:

On Wed, Feb 17, 2016 at 09​:49​:31AM +1100, Tony Cook wrote​:

The only way I can see to avoid references to those dtrace symbols is
to make sure they aren't referenced in the perlmain compilation unit,
whether in an inline function (which appears to be made into a static
function here) or not.

Would it be as simple as wrapping the cx_foo definitions in inline.h with
this?

\#ifndef PERL\_IN\_MINIPERLMAIN\_C

That builds successfully.

Inline Patch

diff --git a/inline.h b/inline.h
index 1e657cc..acee2ad 100644
--- a/inline.h
+++ b/inline.h
@@ -472,6 +472,7 @@ S_cx_topblock(pTHX_ PERL_CONTEXT *cx)
     PL_stack_sp      = PL_stack_base + cx->blk_oldsp;
 }
 
+#ifndef PERL_IN_MINIPERLMAIN_C
 
 PERL_STATIC_INLINE void
 S_cx_pushsub(pTHX_ PERL_CONTEXT *cx, CV *cv, OP *retop, bool hasargs)
@@ -547,6 +548,7 @@ S_cx_popsub(pTHX_ PERL_CONTEXT *cx)
     cx_popsub_common(cx);
 }
 
+#endif
 
 PERL_STATIC_INLINE void
 S_cx_pushformat(pTHX_ PERL_CONTEXT *cx, CV *cv, OP *retop, GV *gv)

> Or are we likely to ru into similar problems when other people try to > embed perl\.so in another application?

No, I think it's safe. We're essentially embedding libperl.so into
perl.

Let me know if you want access to my Solaris VM for testing.

Perhaps that would be best, thanks.

Please send me a ssh pubkey.

It would be handy to know what command-line, env etc you're using to
build perl on it.

./Configure -des -Dusedevel -Dusedtrace -Duseshrplib -DDEBUGGING -Dmake=gmake && gmake -j2 test-prep

hints/solaris.sh picks up the workshop compiler.

Tony

[p5pRT]

From @iabyn

I now have a simple standalone example of this failure​:

With these source files​:

  ==> dtrace.d <==
  provider foo { probe bar(int); };

  ==> inline.h <==
  #include "dtrace.h"
  static void f1() { FOO_BAR(0); }

  ==> a.c <==
  #include "inline.h"
  void f2() { }

  ==> main.c <==
  #include "inline.h"
  int main(int argc, char**argv) { return 0; }

  ==> build <==
  #!/bin/sh
  CC=/opt/solarisstudio12.3/bin/cc
  set -xe
  dtrace -h -s dtrace.d -o dtrace.h
  $CC -c -O -g -KPIC a.c
  $CC -c -O -g -KPIC main.c
  dtrace -G -s dtrace.d -o dtrace.o a.o main.o
  $CC -o liba.so -G a.o dtrace.o
  $CC -o main main.o liba.so
  #$CC -o main main.o a.o dtrace.o # this works
  LD_LIBRARY_PATH=. ./main

running ./build gives​:

  ld.so.1​: main​: fatal​: relocation error​: file ./liba.so​: symbol
  $dtrace5277462.f1​: referenced symbol not found

Looking at symbol tables​:

$ for i in *.o *.so main; do echo $i; nm $i | grep '$dtrace'; done
a.o
[23] | 16| 38|FUNC |GLOB |6 |2 |$dtrace5277444.f1
dtrace.o
[46] | 0| 0|FUNC |GLOB |0 |UNDEF |$dtrace5277444.f1
[47] | 0| 0|FUNC |GLOB |0 |UNDEF |$dtrace5277462.f1
main.o
[25] | 16| 38|FUNC |GLOB |6 |2 |$dtrace5277462.f1
liba.so
[61] | 0| 0|FUNC |GLOB |0 |UNDEF |$dtrace5277462.f1
main

replacing the dynamic link of main in build with
  $CC -o main main.o a.o dtrace.o # this works
works. 'nm main' still doesn't show any $dtrace symbols.

Note that the failure doesn't reply on the equivalent of -DDEBUGGING being
enabled; nor does it require the static function to be "too big".

What seems to happen is that going from main.o to main loses the
$dtrace5277462.f1, so the undef $dtrace5277462.f1 in liba.so can't
subsequently be resolved. Perhaps there's something extra that needs to be
done when building 'main'?

I'm a bit stumped at this point.

--
Lear​: Dost thou call me fool, boy?
Fool​: All thy other titles thou hast given away; that thou wast born with.

[p5pRT]

From @bulk88

On Tue Feb 23 06​:45​:43 2016, davem wrote​:

What seems to happen is that going from main.o to main loses the
$dtrace5277462.f1, so the undef $dtrace5277462.f1 in liba.so can't
subsequently be resolved. Perhaps there's something extra that needs to be
done when building 'main'?

I'm a bit stumped at this point.

Does the order of the .o files passed to the linker matter in resolving symbols?

--
bulk88 ~ bulk88 at hotmail.com