Closed p5pRT closed 11 years ago
This commit:
commit f019c49e380f764c1ead36fe3602184804292711 Author: Daniel Dragan \bulk88@​hotmail\.com Date: Wed Oct 24 16:15:51 2012 -0400
optimize memory wrap croaks\, often used in MEM_WRAP_CHECK
breaks the detection of gcc warning flags by cflags.SH to break.
The cflags.SH script tries to build a simple program that includes the
perl headers and compiles them with various gcc flags.
All those tests now fail with the error message:
/tmp/cc2FFrOt.o: In function `S_croak_memory_wrap': _cflags.c:(.text+0x5): undefined reference to `PL_memory_wrap' _cflags.c:(.text+0x14): undefined reference to `Perl_croak' collect2: error: ld returned 1 exit status
Prior to this patch\, the typical command line used with gcc is something like this:
CCCMD = cc -DPERL_CORE -c -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c89 -O2 -Wall -ansi -W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat -Wwrite-strings
Now\, it is something like
CCCMD = cc -DPERL_CORE -c -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -Wall
Note that all the extra warnings are missing.
The new function S_croak_memory_wrap in inline.h is the culprit. Only static inline functions are supposed to be in inline.h. Making S_croak_memory_wrap a PERL_STATIC_INLINE function fixes the immediate problem\, but defeats the purpose of the original patch. (croaking is definitely not something that normally needs to be inlined.)
On Thu\, Feb 28\, 2013 at 05:41:14AM -0800\, Andy Dougherty wrote:
/tmp/cc2FFrOt.o: In function `S_croak_memory_wrap': _cflags.c:(.text+0x5): undefined reference to `PL_memory_wrap' _cflags.c:(.text+0x14): undefined reference to `Perl_croak' collect2: error: ld returned 1 exit status
PL_memory_wrap isn't used on CPAN. At all.
I think the solution is to replace use of PL_memory_wrap with a string constant. That will avoid the linker failure.
(And also mark the variable as deprecated\, but that doesn't have to be done at the same time)
Nicholas Clark
The RT System itself - Status changed from 'new' to 'open'
On Thu\, 28 Feb 2013\, Nicholas Clark via RT wrote:
On Thu\, Feb 28\, 2013 at 05:41:14AM -0800\, Andy Dougherty wrote:
/tmp/cc2FFrOt.o: In function `S_croak_memory_wrap': _cflags.c:(.text+0x5): undefined reference to `PL_memory_wrap' _cflags.c:(.text+0x14): undefined reference to `Perl_croak' collect2: error: ld returned 1 exit status
PL_memory_wrap isn't used on CPAN. At all.
I think the solution is to replace use of PL_memory_wrap with a string constant. That will avoid the linker failure.
That still leaves the undefined reference to Perl_croak.
The _cflags.c test is being slightly naughty here. It's relying on the copmiler to be smart enough not to link in external things it doesn't need. (And if you set the optimizer high enough\, the compiler will indeed figure out it doesn't need Perl_croak either\, and the error message goes away. The cflags.SH test doesn't run with the optimizer.)
The S_croak_memory_wrap function is also being slightly naughty here.
It's the only non-inline function placed in the inline.h header file.
I have not had a chance to measure the impact of making it back into a
regular external function again.
I did try simply reverting the patch\, but it no longer reverts cleanly.
I'm thinking of trying something like this: It patches the cflags.SH to skip the inline.h file in its testing (and patches inline.h to make such skipping easy.) (It'll probably be a few days before I have time to pursue this further\, however\, so I post it now in case anyone else wants to pursue this.)
Andy Dougherty doughera@lafayette.edu
On Thu\, Feb 28\, 2013 at 10:03:02AM -0500\, Andy Dougherty wrote:
On Thu\, 28 Feb 2013\, Nicholas Clark via RT wrote:
On Thu\, Feb 28\, 2013 at 05:41:14AM -0800\, Andy Dougherty wrote:
/tmp/cc2FFrOt.o: In function `S_croak_memory_wrap': _cflags.c:(.text+0x5): undefined reference to `PL_memory_wrap' _cflags.c:(.text+0x14): undefined reference to `Perl_croak' collect2: error: ld returned 1 exit status
PL_memory_wrap isn't used on CPAN. At all.
I think the solution is to replace use of PL_memory_wrap with a string constant. That will avoid the linker failure.
That still leaves the undefined reference to Perl_croak.
I cheated. See below :-)
The _cflags.c test is being slightly naughty here. It's relying on the copmiler to be smart enough not to link in external things it doesn't need. (And if you set the optimizer high enough\, the compiler will indeed figure out it doesn't need Perl_croak either\, and the error message goes away. The cflags.SH test doesn't run with the optimizer.)
clang is smart enough that it doesn't pull it in.
This was what I had from an earlier experiment:
commit 8694dae014089be4f0c40c96514423aca1bbe2f9 Merge: b4fbebd 120b524 Author: Nicholas Clark \nick@​ccl4\.org Date: Thu Dec 13 08:21:52 2012 +0100
WIP on blead: b4fbebd Data::Dumper is at 2.139
diff --cc cflags.SH
index 899c465\,899c465..f9bae60
--- a/cflags.SH
+++ b/cflags.SH
@@@ -95\,6 -95\,6 +95\,14 @@@ cat >_cflags.c \<\<__EOT_
#ifdef I_SYS_WAIT
#include \<sys/wait.h>
#endif
++
++void
++Perl_croak_nocontext(const char *pat\, ...)
++{
++ /* Avoid warn about unused variables\, or noreturn functions returning. */
++ exit(pat ? 1 : 2);
++}
++
/* The gcc -ansi can cause a lot of noise in Solaris because of:
/usr/include/sys/resource.h:148: warning: 'struct rlimit64' declared inside parameter list
*/
@@@ -132\,6 -132\,6 +140\,26 @@@ stdflags='
# (especially about things like long long\, which are not in C89) will still be
# valid if we now add flags like -std=c89.
++compile="$cc $cflags $warn $stdflags $opt _cflags.c -o _cflags$_exe"
++$compile >_cflags.out 2>&1
++if test ! -x ./_cflags$_exe; then
++ error="$0: can't compile test program."
++elif ./_cflags$_exe; then
++: All is good
++else
++ error="$0: test program did not return true"
++fi
++if test "x$error" != "x"; then
++ echo $error
++ echo "Complied as: $compile"
++ echo Output was:
++ cat _cflags.out
++ if test "x$usedevel" = "xdefine"; then
++ echo "exiting\, as usedevel is defined"
++ exit 2
++ fi
++fi
++
case "$gccversion" in
'') ;;
[12]*) ;; # gcc versions 1 (gasp!) and 2 are not good for this.
@@@ -161\,7 -161\,7 +189\,7 @@@ Intel*) ;; # # Is that you\, Intel C++
done
;;
esac
--rm -f _cflags.c _cflags$_exe
++rm -f _cflags.c _cflags$_exe _cflags.out
case "$gccversion" in
'') ;;
diff --cc inline.h
index b321cc2\,b321cc2..ff222f6
--- a/inline.h
+++ b/inline.h
@@@ -133\,7 -133\,7 +133\,7 @@@ S_sv_or_pv_pos_u2b(pTHX_ SV *sv\, const
static void
S_croak_memory_wrap(void)
{
-- Perl_croak_nocontext("%s"\,PL_memory_wrap);
++ Perl_croak_nocontext("panic: memory wrap");
}
#ifdef __clang__
#pragma clang diagnostic pop
I hadn't cleaned it up enough to be confident of testing it.
In particular\, I was trying also to add a self-check\, so that with -Dusedevel this didn't happen again.
Nicholas Clark
On Thu Feb 28 05:51:58 2013\, nicholas wrote:
On Thu\, Feb 28\, 2013 at 05:41:14AM -0800\, Andy Dougherty wrote:
/tmp/cc2FFrOt.o: In function `S_croak_memory_wrap': _cflags.c:(.text+0x5): undefined reference to `PL_memory_wrap' _cflags.c:(.text+0x14): undefined reference to `Perl_croak' collect2: error: ld returned 1 exit status
PL_memory_wrap isn't used on CPAN. At all.
PL_memory_wrap is exported\, darkpan code could be using it. More controversy to remove it (deprecate is not removing) than leave it alone. Also to make it a literal would add 19 bytes in many/every XS module. Using the export on Win32 is sizeof(void*)/*PE file member*/ + 4 /*PE file member\, U32 offset to string from image start*/ + (sizeof("PL_memory_wrap")) bytes for a total of 22 bytes on 32 bits. Hmm\, might as well remove the PL_memory_wrap and replace it with the literal. I thought at the time\, if you can't remove it\, use it. Guess I was wrong. (I thought sizeof("PL_memory_wrap") \< sizeof("panic: memory wrap"))
I think someone else once said for maintenance reason you can not replace PL_memory_wrap (or its equivalents) with the string literal. The idea was that Perl one day will need a internationalization API so it isn't anglocentric\, so dont make it harder than it already is to internationalize Perl. The messages the interp spits out in perldiag come in your native language when the interp prints them to console\, not english.
I think the solution is to replace use of PL_memory_wrap with a string constant. That will avoid the linker failure.
What about the Perl_croak func?
Why doesn't the linker remove unused functions? I am not very familiar with SysV ABI but can you/anyone tell GCC to turn off "visibility" for S_croak_memory_wrap? If "visibility" [optimization] ( http://gcc.gnu.org/wiki/Visibility ) does what I think it does (not a penguin person)\, I am surprised greping the repo only produced http://perl5.git.perl.org/perl.git/blob/41191e557c536be3754384dee54e7700ca3df256:/cpan/Compress-Raw-Zlib/zlib-src/zutil.h#l21 as the only hit.
Why does cflags.SH include perl's headers without the linking lib? One choice is to add an #include guard\, then define the guard in cflags.SH to not include inline.h before "#include "perl.h"" since the exec that is compile will never (assuming) be linked with perl.
Another choice is to make a macro that does Perl_croak_memory_wrap (regular old exported)
or
S_croak_memory_wrap
depending on platform. Looking at my VC 2008 x64 blead perl just now\, S_croak_memory_wrap was inlined everywhere\, and Perl_croak_no_modify (another slim croak path I created) in the interp was inlined everywhere and a separate copy exists for export purposes\, but in XS modules Perl_croak_no_modify is just 1 instruction \, so I will have to look at that now. I dont have an example of Perl_croak_no_modify in asm in a XS module underhand\, so here is Perl_croak_popstack (exported) from an XS module. The int 3 is what VC does on many "noreturns". Ideally a jmp is best\, but that can destroy callstacks (or make 1 frame disappear) in a debugger due to no return address being known if its symbols aren't very advanced*(see below)\, so I guess VC makes the choice to call instead of jmp in this case.
//from an VC x64 XS module
0000000180001D83 75 07 jnz 180001D8C
0000000180001D85 FF 15 0D 34 00 00 call
cs:__imp_Perl_croak_popstack
0000000180001D8B CC int 3
FWIW\, ppport.h and MS's Win32 API headers both define statics in .h files.
*low level compiler design ahead\, skip if you want\, VC with static/random-calling-convention-ok funcs will generate functions which use the caller's C autos directly reaching behind the static's return to caller instruction address\, no &some_auto_struct pointer placed on C stack then derefed in callee. If a static func has only 1 caller or can be tailcalled\, it can be turned into a series of jmps\, and use the caller's stack frame (no return address to caller). Symbols will know by instruction address that this is a different function\, but a disassembler says it is the same function. I dont want to say "inlined" since sometimes a func will do a jmp into another func because it and another func share the same branch with a return at the end of\, C wise so compiler finds 2 funcs have same ending (including restore non-vols regs in the same order off C stack) and 1 jmps to the other. In C it would be a goto a label in a different func.
-- bulk88 ~ bulk88 at hotmail.com
On Thu\, 28 Feb 2013\, bulk88 via RT wrote:
On Thu Feb 28 05:51:58 2013\, nicholas wrote:
On Thu\, Feb 28\, 2013 at 05:41:14AM -0800\, Andy Dougherty wrote:
/tmp/cc2FFrOt.o: In function `S_croak_memory_wrap': _cflags.c:(.text+0x5): undefined reference to `PL_memory_wrap' _cflags.c:(.text+0x14): undefined reference to `Perl_croak' collect2: error: ld returned 1 exit status
What about the Perl_croak func?
Why doesn't the linker remove unused functions? I am not very familiar with SysV ABI but can you/anyone tell GCC to turn off "visibility" for S_croak_memory_wrap? If "visibility" [optimization] ( http://gcc.gnu.org/wiki/Visibility ) does what I think it does (not a penguin person)\, I am surprised greping the repo only produced http://perl5.git.perl.org/perl.git/blob/41191e557c536be3754384dee54e7700ca3df256:/cpan/Compress-Raw-Zlib/zlib-src/zutil.h#l21 as the only hit.
Empirically\, the linker does remove unused functions if a sufficiently high level of optimization is set. cflags.SH currently doesn't run with a high enough level of optimization. Temporarily overriding the optimization is one option I considered\, but didn't pursue in case the user had put some other relevant flags in $Config{optimize} that shouldn't be overridden.
Why does cflags.SH include perl's headers without the linking lib?
Because there is no "linking lib" yet. cflags.SH runs just after Configure finishes. Nothing has been compiled yet.
One
choice is to add an #include guard\, then define the guard in cflags.SH to not include inline.h before "#include "perl.h"" since the exec that is compile will never (assuming) be linked with perl.
I posted a patch that did this\, but it has the drawback that the test doesn't include \<inline.h>\, so we might pick warning flags that will cause us problems when we eventually do include \<inline.h>. Alternatively\, Nicholas has experimented with adding a Perl_croak function to the cflags test. I haven't looked at that yet\, but it might be a better choice.
Another choice is to make a macro that does Perl_croak_memory_wrap (regular old exported)
or
S_croak_memory_wrap
depending on platform.
I didn't think of that\, but it feels like it's trying to solve the wrong problem.
One of the underlying issues is that S_croak_memory_wrap is an odd duck. It's the only non-inline function in \<inline.h>. As such\, it's forcing us to invent workarounds. I wonder if the better fix will ultimately be to not have a non-inline function in \<inline.h> and look for a different solution to the original problem that led to this situation in the first place.
The other underlying issue is that cflags.SH is doing some strange things too -- it's trying to anticipate problems before they happen. The warnings that it does turn up are occasionally helpful\, so I'm inclined to leave the cflags.SH mechanism in place and try to get it working again.
-- Andy Dougherty doughera@lafayette.edu
perl.h includes inline.h\, which has inline functions referencing real funcitons in libperl\, breaking linkin any program that includes perl.h but doesn't link against libperl. This breaks Time::HiRes' configure probes\, causing it to lack functionality like clock_gettime even if it's supported by the OS.
ilmari@nurket:\~/src/Time-HiRes-1.9725$ VERBOSE=1 perl Makefile.PL Configuring Time::HiRes... Using hints hints/linux.pl... Extra libraries: -lrt... Have syscall()... looking for syscall.h... cccmd = cc -o tmp28721 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/ilmari/perl5/perlbrew/perls/perl-5.17.10/lib/5.17.10/x86_64-linux/CORE tmp28721.c -lrt /tmp/ccH7Tt2Z.o: In function `S_croak_memory_wrap': tmp28721.c:(.text+0x5): undefined reference to `PL_memory_wrap' tmp28721.c:(.text+0x14): undefined reference to `Perl_croak' collect2: error: ld returned 1 exit status cccmd = cc -o tmp28721 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/ilmari/perl5/perlbrew/perls/perl-5.17.10/lib/5.17.10/x86_64-linux/CORE tmp28721.c -lrt /tmp/ccZ5Fkz0.o: In function `S_croak_memory_wrap': tmp28721.c:(.text+0x5): undefined reference to `PL_memory_wrap' tmp28721.c:(.text+0x14): undefined reference to `Perl_croak' collect2: error: ld returned 1 exit status NOT found. Looking for gettimeofday()... found. Looking for setitimer()... found. Looking for getitimer()... found. You have interval timers (both setitimer and getitimer). Looking for ualarm()... found. Looking for usleep()... found. Looking for nanosleep()... testing... cccmd = cc -o tmp28721 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/ilmari/perl5/perlbrew/perls/perl-5.17.10/lib/5.17.10/x86_64-linux/CORE tmp28721.c -lrt Running ./tmp28721...found. You can mix subsecond sleeps with signals\, if you want to. (It's still not portable\, though.) Looking for clock_gettime()... cccmd = cc -o tmp28721 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/ilmari/perl5/perlbrew/perls/perl-5.17.10/lib/5.17.10/x86_64-linux/CORE tmp28721.c -lrt /tmp/ccRvKBJ3.o: In function `S_croak_memory_wrap': tmp28721.c:(.text+0x5): undefined reference to `PL_memory_wrap' tmp28721.c:(.text+0x14): undefined reference to `Perl_croak' collect2: error: ld returned 1 exit status NOT found. Looking for clock_getres()... cccmd = cc -o tmp28721 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/ilmari/perl5/perlbrew/perls/perl-5.17.10/lib/5.17.10/x86_64-linux/CORE tmp28721.c -lrt /tmp/cc3exavg.o: In function `S_croak_memory_wrap': tmp28721.c:(.text+0x5): undefined reference to `PL_memory_wrap' tmp28721.c:(.text+0x14): undefined reference to `Perl_croak' collect2: error: ld returned 1 exit status NOT found. Looking for clock_nanosleep()... cccmd = cc -o tmp28721 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/ilmari/perl5/perlbrew/perls/perl-5.17.10/lib/5.17.10/x86_64-linux/CORE tmp28721.c -lrt /tmp/cc7hXQss.o: In function `S_croak_memory_wrap': tmp28721.c:(.text+0x5): undefined reference to `PL_memory_wrap' tmp28721.c:(.text+0x14): undefined reference to `Perl_croak' collect2: error: ld returned 1 exit status NOT found. Looking for clock()... cccmd = cc -o tmp28721 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/ilmari/perl5/perlbrew/perls/perl-5.17.10/lib/5.17.10/x86_64-linux/CORE tmp28721.c -lrt /tmp/ccq16SGE.o: In function `S_croak_memory_wrap': tmp28721.c:(.text+0x5): undefined reference to `PL_memory_wrap' tmp28721.c:(.text+0x14): undefined reference to `Perl_croak' collect2: error: ld returned 1 exit status NOT found. Looking for stat() subsecond timestamps... Trying struct stat st_atimespec.tv_nsec...cccmd = cc -o tmp28721 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/ilmari/perl5/perlbrew/perls/perl-5.17.10/lib/5.17.10/x86_64-linux/CORE tmp28721.c -lrt tmp28721.c: In function âmainâ: tmp28721.c:17:7: error: âstruct statâ has no member named âst_atimespecâ NOT found. Trying struct stat st_atimensec...cccmd = cc -o tmp28721 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/ilmari/perl5/perlbrew/perls/perl-5.17.10/lib/5.17.10/x86_64-linux/CORE tmp28721.c -lrt tmp28721.c: In function âmainâ: tmp28721.c:17:7: error: âstruct statâ has no member named âst_atimensecâ NOT found. Trying struct stat st_atime_n...cccmd = cc -o tmp28721 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/ilmari/perl5/perlbrew/perls/perl-5.17.10/lib/5.17.10/x86_64-linux/CORE tmp28721.c -lrt tmp28721.c: In function âmainâ: tmp28721.c:17:7: error: âstruct statâ has no member named âst_atime_nâ NOT found. Trying struct stat st_atim.tv_nsec...cccmd = cc -o tmp28721 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/ilmari/perl5/perlbrew/perls/perl-5.17.10/lib/5.17.10/x86_64-linux/CORE tmp28721.c -lrt /tmp/ccpnxcyb.o: In function `S_croak_memory_wrap': tmp28721.c:(.text+0x5): undefined reference to `PL_memory_wrap' tmp28721.c:(.text+0x14): undefined reference to `Perl_croak' collect2: error: ld returned 1 exit status NOT found. Trying struct stat st_uatime...cccmd = cc -o tmp28721 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/ilmari/perl5/perlbrew/perls/perl-5.17.10/lib/5.17.10/x86_64-linux/CORE tmp28721.c -lrt tmp28721.c: In function âmainâ: tmp28721.c:17:7: error: âstruct statâ has no member named âst_uatimeâ NOT found. You do not seem to have stat subsecond timestamps. Checking if your kit is complete... Looks good Processing hints file hints/linux.pl Writing Makefile for Time::HiRes Writing MYMETA.yml and MYMETA.json Now you may issue 'make'. Do not forget also 'make test'. ilmari@nurket:\~/src/Time-HiRes-1.9725$
Dagfinn Ilmari MannsĂ„ker (via RT) \perlbug\-followup@​perl\.org writes:
perl.h includes inline.h\, which has inline functions referencing real funcitons in libperl\, breaking linkin any program that includes perl.h but doesn't link against libperl.
Btw\, Nicholas says this should block 5.18:
\<@Nicholas> ilmari: this is a bug we need to fix \<@Nicholas> wasn't aware that it broke Time::HiRes too \<@ilmari> it breaks subtly \<@ilmari> it doesn't fail to build or test\, just misses a bunch of features \<@Nicholas> I think that this needs to become a blocker \<@ilmari> severity? high? \<@Nicholas> I think high\, yes \<@Nicholas> if it's breaking stuff at runtime without warning\, I think it's high
-- "The surreality of the universe tends towards a maximum" -- Skud's Law "Never formulate a law or axiom that you're not prepared to live with the consequences of." -- Skud's Meta-Law
On Sun Mar 24 06:47:06 2013\, ilmari wrote:
This is a bug report for perl from ilmari@ilmari.org\, generated with the help of perlbug 1.39 running under perl 5.17.10.
----------------------------------------------------------------- [Please describe your issue here]
perl.h includes inline.h\, which has inline functions referencing real funcitons in libperl\, breaking linkin any program that includes perl.h but doesn't link against libperl. This breaks Time::HiRes' configure probes\, causing it to lack functionality like clock_gettime even if it's supported by the OS.
This sounds related to https://rt-archive.perl.org/perl5/Ticket/Display.html?id=116989 -- bulk88 ~ bulk88 at hotmail.com
The RT System itself - Status changed from 'new' to 'open'
On Thu Feb 28 08:54:28 2013\, doughera wrote:
Empirically\, the linker does remove unused functions if a sufficiently high level of optimization is set. cflags.SH currently doesn't run with a high enough level of optimization. Temporarily overriding the optimization is one option I considered\, but didn't pursue in case the user had put some other relevant flags in $Config{optimize} that shouldn't be overridden.
Maybe -funit-at-a-time is what does it (remove unused statics).
-- bulk88 ~ bulk88 at hotmail.com
This seems to be a regression:
$ perl5.16.3 -MTime::HiRes -le 'print Time::HiRes::clock_gettime (Time::HiRes::CLOCK_MONOTONIC ())' 1597643.86352558 $ perl5.17.10 -MTime::HiRes -le 'print Time::HiRes::clock_gettime (Time::HiRes::CLOCK_MONOTONIC ())' Time::HiRes::clock_gettime(): unimplemented in this platform at -e line 1.
This is\, I think\, the root cause of the failure:
http://www.cpantesters.org/cpan/report/fb45c356-93f5-11e2-8b69-0a4fc51cef80
Darin McBride (via RT) \perlbug\-followup@​perl\.org writes:
This seems to be a regression:
$ perl5.16.3 -MTime::HiRes -le 'print Time::HiRes::clock_gettime (Time::HiRes::CLOCK_MONOTONIC ())' 1597643.86352558 $ perl5.17.10 -MTime::HiRes -le 'print Time::HiRes::clock_gettime (Time::HiRes::CLOCK_MONOTONIC ())' Time::HiRes::clock_gettime(): unimplemented in this platform at -e line 1.
This is caused by the same header problem as:
https://rt-archive.perl.org/perl5/Public/Bug/Display.html?id=117319 https://rt-archive.perl.org/perl5/Public/Bug/Display.html?id=116989
-- "The surreality of the universe tends towards a maximum" -- Skud's Law "Never formulate a law or axiom that you're not prepared to live with the consequences of." -- Skud's Meta-Law
The RT System itself - Status changed from 'new' to 'open'
On Mon\, Mar 25\, 2013 at 09:36:05AM +0100\, Dagfinn Ilmari MannsÄker wrote:
Darin McBride (via RT) \perlbug\-followup@​perl\.org writes:
This seems to be a regression:
$ perl5.16.3 -MTime::HiRes -le 'print Time::HiRes::clock_gettime (Time::HiRes::CLOCK_MONOTONIC ())' 1597643.86352558 $ perl5.17.10 -MTime::HiRes -le 'print Time::HiRes::clock_gettime (Time::HiRes::CLOCK_MONOTONIC ())' Time::HiRes::clock_gettime(): unimplemented in this platform at -e line 1.
This is caused by the same header problem as:
https://rt-archive.perl.org/perl5/Public/Bug/Display.html?id=117319 https://rt-archive.perl.org/perl5/Public/Bug/Display.html?id=116989
I have merged all these tickets.
I haven't yet been hit with inspiration on how to solve the problem whilst preserving the intent of the changes which inadvertently caused it.
Nicholas Clark
On Mon Mar 25 02:12:34 2013\, nicholas wrote:
On Mon\, Mar 25\, 2013 at 09:36:05AM +0100\, Dagfinn Ilmari Mannsïżœker wrote:
Darin McBride (via RT) \perlbug\-followup@​perl\.org writes:
This seems to be a regression:
$ perl5.16.3 -MTime::HiRes -le 'print Time::HiRes::clock_gettime (Time::HiRes::CLOCK_MONOTONIC ())' 1597643.86352558 $ perl5.17.10 -MTime::HiRes -le 'print Time::HiRes::clock_gettime (Time::HiRes::CLOCK_MONOTONIC ())' Time::HiRes::clock_gettime(): unimplemented in this platform at -e line 1.
This is caused by the same header problem as:
https://rt-archive.perl.org/perl5/Public/Bug/Display.html?id=117319 https://rt-archive.perl.org/perl5/Public/Bug/Display.html?id=116989
I have merged all these tickets.
I haven't yet been hit with inspiration on how to solve the problem whilst preserving the intent of the changes which inadvertently caused it.
Making croak_memory_map() into an exported API function would retain most of the savings while reducing the pain\, I think.
Tony
On Tue\, 26 Mar 2013\, Tony Cook via RT wrote:
On Mon Mar 25 02:12:34 2013\, nicholas wrote:
On Mon\, Mar 25\, 2013 at 09:36:05AM +0100\, Dagfinn Ilmari Manns???ker wrote:
Darin McBride (via RT) \perlbug\-followup@​perl\.org writes:
This seems to be a regression:
$ perl5.16.3 -MTime::HiRes -le 'print Time::HiRes::clock_gettime (Time::HiRes::CLOCK_MONOTONIC ())' 1597643.86352558 $ perl5.17.10 -MTime::HiRes -le 'print Time::HiRes::clock_gettime (Time::HiRes::CLOCK_MONOTONIC ())' Time::HiRes::clock_gettime(): unimplemented in this platform at -e line 1.
This is caused by the same header problem as:
https://rt-archive.perl.org/perl5/Public/Bug/Display.html?id=117319 https://rt-archive.perl.org/perl5/Public/Bug/Display.html?id=116989
I have merged all these tickets.
I haven't yet been hit with inspiration on how to solve the problem whilst preserving the intent of the changes which inadvertently caused it.
Making croak_memory_map() into an exported API function would retain most of the savings while reducing the pain\, I think.
This is the tact I tried in commit f8fd8bfff8eb57156a0ab858d4c185701258b0e3 in branch remotes/origin/smoke-me/andyd/croak_memory_wrap.
I'd welcome feedback. I'm no longer sure it ends up saving anything compared to the original Perl_croak_nocontext("%s"\, PL_memory_wrap)\, but this seemed like the best way forward for now.
-- Andy Dougherty doughera@lafayette.edu
On Wed Mar 27 13:11:35 2013\, doughera wrote:
This is the tact I tried in commit f8fd8bfff8eb57156a0ab858d4c185701258b0e3 in branch remotes/origin/smoke-me/andyd/croak_memory_wrap.
I'd welcome feedback. I'm no longer sure it ends up saving anything compared to the original Perl_croak_nocontext("%s"\, PL_memory_wrap)\, but this seemed like the best way forward for now.
Summary\, on Win32\, new way (8 bytes) is slightly worse than before (5 or 7 bytes)\, but still better than the original situation (19 bytes). Its ok.
On Win32 (not discussing any other OS)\, Perl_croak_memory_wrap is still a savings. On VC 2003 32 bit \, it will now probably (I didn't compile f8fd8bfff8eb57156a0ab858d4c185701258b0e3) be ____________________________________________ jmp_conditional didnt_wrap (2 bytes) call *(image_import_table_Perl_croak_memory_wrap) (6 bytes) didn't_wrap: ____________________________________________ which is still shorter than ________________________________________________ jmp_conditional didnt_wrap (2 bytes) push *(image_import_table_PL_memory_wrap) (6 bytes) push in_image_%s_fmt_string (5 bytes) call *(image_import_table_Perl_croak_nocontext) (6 bytes) didn't_wrap: ________________________________________________
As a static non-inline previously\, *ideally* (C compiler dependent) it would have been ________________________________________________ jmp_conditional relative_to_croak_memory_wrap (5 bytes) ________________________________________________
Visual C 2003 in 32 bit mode I remember did ________________________________________________ jmp_conditional didnt_wrap (2 bytes) jmp_unconditional in_image_S_croak_memory_wrap (5 bytes) didn't_wrap: ________________________________________________ which is strange and unideal\, (I will guess\, in the internal design of VC\, it probably has to do with the 1st jump being a flow control bytecode op\, and the 2nd jump being the func call bytecode op).
In theory\, a C compiler could do (VC will do this in debug mode to enable http://msdn.microsoft.com/en-us/library/bcew296c%28v=vs.80%29.aspx )\, looking at my 5.12 Strawberry (GCC -O2)\, it does NOT do this)
________________________________________________ jmp_conditional relative_to_Perl_croak_memory_wrap_stub (5 bytes) didn't_wrap: ________________________________________________ somewhere else in the image\, once per image\, there is the following function ________________________________________________ jmp_unconditional *(image_import_table_Perl_croak_memory_wrap) (6 bytes) ________________________________________________
But I guess there is a performance problem with doing that so it just isn't done by any Windows C compiler in an optimized build.
-- bulk88 ~ bulk88 at hotmail.com
On 3/25/13 1:26 AM\, Darin McBride wrote:
# New Ticket Created by Darin McBride # Please include the string: [perl #117331] # in the subject line of all future correspondence about this issue. #\<URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=117331>
This is a bug report for perl from dmcbride@cpan.org\, generated with the help of perlbug 1.39 running under perl 5.17.10.
----------------------------------------------------------------- [Please describe your issue here]
This seems to be a regression:
$ perl5.16.3 -MTime::HiRes -le 'print Time::HiRes::clock_gettime (Time::HiRes::CLOCK_MONOTONIC ())' 1597643.86352558 $ perl5.17.10 -MTime::HiRes -le 'print Time::HiRes::clock_gettime (Time::HiRes::CLOCK_MONOTONIC ())' Time::HiRes::clock_gettime(): unimplemented in this platform at -e line 1.
Well\, FWIW\, it's not implemented on this older Darwin\, either:
##### $ perl -V Summary of my perl5 (revision 5 version 16 subversion 0) configuration:
Platform: osname=darwin\, osvers=8.11.0\, archname=darwin-2level uname='darwin macintosh-8.local 8.11.0 darwin kernel version 8.11.0: wed oct 10 18:26:00 pdt 2007; root:xnu-792.24.17~1release_ppc power macintosh powerpc ' ... ccversion=''\, gccversion='4.0.1 (Apple Computer\, Inc. build 5250)'\, gccosandvers='' intsize=4\, longsize=4\, ptrsize=4\, doublesize=8\, byteorder=4321 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=16 ivtype='long'\, ivsize=4\, nvtype='double'\, nvsize=8\, Off_t='off_t'\, lseeksize=8 alignbytes=8\, prototype=define ...
$ perl -MTime::HiRes -le 'print Time::HiRes::clock_gettime (Time::HiRes::CLOCK_MONOTONIC ())' Your vendor has not defined Time::HiRes macro CLOCK_MONOTONIC\, used at -e line 1.
On 3/27/13 4:10 PM\, Andy Dougherty wrote:
Making croak_memory_map() into an exported API function would retain most of the savings while reducing the pain\, I think.
This is the tact I tried in commit f8fd8bfff8eb57156a0ab858d4c185701258b0e3 in branch remotes/origin/smoke-me/andyd/croak_memory_wrap.
I'd welcome feedback. I'm no longer sure it ends up saving anything compared to the original Perl_croak_nocontext("%s"\, PL_memory_wrap)\, but this seemed like the best way forward for now.
PASS all tests on Darwin/PPC (but see other post in thread).
On Wed Mar 27 18:00:17 2013\, bulk88 wrote:
Summary\, on Win32\, new way (8 bytes) is slightly worse than before (5 or 7 bytes)\, but still better than the original situation (19 bytes). Its ok.
On Win32 (not discussing any other OS)\, Perl_croak_memory_wrap is still a savings. On VC 2003 32 bit \, it will now probably (I didn't compile f8fd8bfff8eb57156a0ab858d4c185701258b0e3) be ____________________________________________ jmp_conditional didnt_wrap (2 bytes) call *(image_import_table_Perl_croak_memory_wrap) (6 bytes) didn't_wrap: ____________________________________________ which is still shorter than ________________________________________________ jmp_conditional didnt_wrap (2 bytes) push *(image_import_table_PL_memory_wrap) (6 bytes) push in_image_%s_fmt_string (5 bytes) call *(image_import_table_Perl_croak_nocontext) (6 bytes) didn't_wrap: ________________________________________________
As a static non-inline previously\, *ideally* (C compiler dependent) it would have been ________________________________________________ jmp_conditional relative_to_croak_memory_wrap (5 bytes) ________________________________________________
Visual C 2003 in 32 bit mode I remember did ________________________________________________ jmp_conditional didnt_wrap (2 bytes) jmp_unconditional in_image_S_croak_memory_wrap (5 bytes) didn't_wrap: ________________________________________________ which is strange and unideal\, (I will guess\, in the internal design of VC\, it probably has to do with the 1st jump being a flow control bytecode op\, and the 2nd jump being the func call bytecode op).
In theory\, a C compiler could do (VC will do this in debug mode to enable http://msdn.microsoft.com/en-us/library/bcew296c%28v=vs.80%29.aspx )\, looking at my 5.12 Strawberry (GCC -O2)\, it does NOT do this)
________________________________________________ jmp_conditional relative_to_Perl_croak_memory_wrap_stub (5 bytes) didn't_wrap: ________________________________________________ somewhere else in the image\, once per image\, there is the following function ________________________________________________ jmp_unconditional *(image_import_table_Perl_croak_memory_wrap) (6 bytes) ________________________________________________
But I guess there is a performance problem with doing that so it just isn't done by any Windows C compiler in an optimized build.
Forgot to mention\, the above numbers assume croak_memory_wrap() is a XS library\, not the interp (perl517.dll). They also assume the compiler wasn't set to "aggressive inline" mode and inlined all the S_croak_memory_wrap calls\, which could happen. Inside the interp\, a jmp_conditional relative_32_bits_to_current_instruction_register can still be done\, since it is within the same image.
-- bulk88 ~ bulk88 at hotmail.com
On Wed\, 27 Mar 2013\, Andy Dougherty wrote:
On Tue\, 26 Mar 2013\, Tony Cook via RT wrote:
On Mon Mar 25 02:12:34 2013\, nicholas wrote:
On Mon\, Mar 25\, 2013 at 09:36:05AM +0100\, Dagfinn Ilmari Manns???ker wrote:
Darin McBride (via RT) \perlbug\-followup@​perl\.org writes:
This seems to be a regression:
$ perl5.16.3 -MTime::HiRes -le 'print Time::HiRes::clock_gettime (Time::HiRes::CLOCK_MONOTONIC ())' 1597643.86352558 $ perl5.17.10 -MTime::HiRes -le 'print Time::HiRes::clock_gettime (Time::HiRes::CLOCK_MONOTONIC ())' Time::HiRes::clock_gettime(): unimplemented in this platform at -e line 1.
This is caused by the same header problem as:
https://rt-archive.perl.org/perl5/Public/Bug/Display.html?id=117319 https://rt-archive.perl.org/perl5/Public/Bug/Display.html?id=116989
I have merged all these tickets.
I haven't yet been hit with inspiration on how to solve the problem whilst preserving the intent of the changes which inadvertently caused it.
Making croak_memory_map() into an exported API function would retain most of the savings while reducing the pain\, I think.
This is the tact I tried in commit f8fd8bfff8eb57156a0ab858d4c185701258b0e3 in branch remotes/origin/smoke-me/andyd/croak_memory_wrap.
I'd welcome feedback. I'm no longer sure it ends up saving anything compared to the original Perl_croak_nocontext("%s"\, PL_memory_wrap)\, but this seemed like the best way forward for now.
I've now applied this fix in commit 43387ee1abcd83c3c7586b7f7aa86e838d239aac
Remove the non-inline function S_croak_memory_wrap from inline.h.
This appears to resolve these three related tickets:
[perl #116989] S_croak_memory_wrap breaks gcc warning flags detection
[perl #117319] Can't include perl.h without linking to libperl
[perl #117331] Time::HiRes::clock_gettime not implemented on Linux (regression?)
--
Andy Dougherty doughera@lafayette.edu
On Wed Mar 27 18:00:17 2013\, bulk88 wrote:
jmp_conditional relative_to_croak_memory_wrap (5 bytes) ________________________________________________
________________________________________________ jmp_conditional relative_to_Perl_croak_memory_wrap_stub (5 bytes) didn't_wrap: ________________________________________________
As TonyC mentioned on IRC\, the above is 6 bytes\, not 5. My mistake.
-- bulk88 ~ bulk88 at hotmail.com
On Wed Mar 27 13:11:35 2013\, doughera wrote:>
This is the tact I tried in commit f8fd8bfff8eb57156a0ab858d4c185701258b0e3 in branch remotes/origin/smoke-me/andyd/croak_memory_wrap.
I'd welcome feedback. I'm no longer sure it ends up saving anything compared to the original Perl_croak_nocontext("%s"\, PL_memory_wrap)\, but this seemed like the best way forward for now.
I know you already merged it\, but what is SHA 380f764c1ead36fe3602184804292711? I created the old scheme in http://perl5.git.perl.org/perl.git/commit/f019c49e380f764c1ead36fe3602184804292711?f=inline.h . Wait\, that was a copy paste mistake? -- bulk88 ~ bulk88 at hotmail.com
On Fri\, 29 Mar 2013\, bulk88 via RT wrote:
On Wed Mar 27 13:11:35 2013\, doughera wrote:>
This is the tact I tried in commit f8fd8bfff8eb57156a0ab858d4c185701258b0e3 in branch remotes/origin/smoke-me/andyd/croak_memory_wrap.
I'd welcome feedback. I'm no longer sure it ends up saving anything compared to the original Perl_croak_nocontext("%s"\, PL_memory_wrap)\, but this seemed like the best way forward for now.
I know you already merged it\, but what is SHA 380f764c1ead36fe3602184804292711? I created the old scheme in http://perl5.git.perl.org/perl.git/commit/f019c49e380f764c1ead36fe3602184804292711?f=inline.h . Wait\, that was a copy paste mistake?
I'm sorry\, but I have no idea what you mean here.
-- Andy Dougherty doughera@lafayette.edu
On Fri Mar 29 06:53:21 2013\, doughera wrote:
On Fri\, 29 Mar 2013\, bulk88 via RT wrote:
I know you already merged it\, but what is SHA 380f764c1ead36fe3602184804292711? I created the old scheme in
http://perl5.git.perl.org/perl.git/commit/f019c49e380f764c1ead36fe3602184804292711?f=inline.h
. Wait\, that was a copy paste mistake?
I'm sorry\, but I have no idea what you mean here.
Goto http://perl5.git.perl.org/perl.git/commit/43387ee1abcd83c3c7586b7f7aa86e838d239aac and click on "380f764c1ead36fe3602184804292711" in the commit message. I am just pointing out a typo in the commit message.
Another topic\, what is the criteria for closing this ticket? A patch was already committed\, so its about time for this ticket to be closed\, are we waiting for confirmation libperl isn't mandatory to be linked in anymore in the various manifestations of the problem mentioned above?
-- bulk88 ~ bulk88 at hotmail.com
On Fri\, 29 Mar 2013\, bulk88 via RT wrote:
Another topic\, what is the criteria for closing this ticket? A patch was already committed\, so its about time for this ticket to be closed\, are we waiting for confirmation libperl isn't mandatory to be linked in anymore in the various manifestations of the problem mentioned above?
Ideally\, I would like to have a test such that we can detect this sort of issue sooner. I'm imagining a test that extracts the C test program from cflags.SH and tries to compile and run it. Such a test would be part of the perl test suite so that it is run even by systems that don't run Configure.
Alas\, I have no time to create such a test right now.
-- Andy Dougherty doughera@lafayette.edu
On Wed Apr 03 04:25:21 2013\, doughera wrote:
On Fri\, 29 Mar 2013\, bulk88 via RT wrote:
Another topic\, what is the criteria for closing this ticket? A patch was already committed\, so its about time for this ticket to be closed\, are we waiting for confirmation libperl isn't mandatory to be linked in anymore in the various manifestations of the problem mentioned above?
Ideally\, I would like to have a test such that we can detect this sort of issue sooner. I'm imagining a test that extracts the C test program from cflags.SH and tries to compile and run it. Such a test would be part of the perl test suite so that it is run even by systems that don't run Configure.
Alas\, I have no time to create such a test right now.
I've written a test for this issue\, currently pushed to smoke-me/tonyc/extrefs.
It's based on the Time-HiRes build code rather than cflags.SH\, but does fail if I add a static function referencing Perl_croak_nocontext to inline.h.
Tested locally on Win32\, cygwin\, Linux.
Tony
On Sat\, 13 Apr 2013\, Tony Cook via RT wrote:
I've written a test for this issue\, currently pushed to smoke-me/tonyc/extrefs.
It's based on the Time-HiRes build code rather than cflags.SH\, but does fail if I add a static function referencing Perl_croak_nocontext to inline.h.
Tested locally on Win32\, cygwin\, Linux.
Thank you for writing this test. Unfortunately\, it fails on Solaris 11 with Sun's compiler:
porting/extrefs.t .. 1..1 cccmd = cc -o temp -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV -I.. temp.c Undefined first referenced symbol in file Perl_mg_size temp.o Perl__is_utf8_perl_idstart temp.o PL_charclass temp.o Perl_sv_free2 temp.o Perl__is_utf8_FOO temp.o ld: fatal: symbol referencing errors. No output written to temp not ok 1 # Failed test 1 - at porting/extrefs.t line 29 Failed 1/1 subtests
The test is fine\, and is testing what I wanted to test. It's just that 5.17's new inline.h header references external functions and compilers aren't always clever enough to figure out that they are ultimately unneeded. For gcc\, either the 'static inline' clue or setting a higher optimization level is enough for the compiler to figure out that the symbols are ultimately unneeded. I had hoped other compilers would act similarly\, but Sun's CC\, in the absence of optimization\, doesn't figure it out.
I didn't have a chance to check the smoke logs to see if any other compilers passed the test or not.
(So others don't have to go digging: The test simply tries to compile the following simple program:
#include "EXTERN.h" #include "perl.h" #include "XSUB.h"
int main(int argc\, char **argv) { return 0; }
without linking to libperl.a.)
I'm not sure what the best thing to do here is. This is definitely a regression since 5.16. It affects the feature probes in Time::HiRes.
I don't see a simple fix. Adding $Config{optimize} to the compile command line (and also in Time::HiRes) works around the problem in the common case\, but still won't work if optimize=-g or some such.
I had originally hoped that adding static inline functions would allow us to clean up some of the complicated duplicated macros (especially ones that have different forms for gcc) and simplify the source. Now I'm not so sure. I'm afraid I don't have any proposal to offer at the moment\, but I hope someone else will think of something.
-- Andy Dougherty doughera@lafayette.edu
On Wed\, Apr 17\, 2013 at 09:17:17AM -0400\, Andy Dougherty wrote:
On Sat\, 13 Apr 2013\, Tony Cook via RT wrote:
I've written a test for this issue\, currently pushed to smoke-me/tonyc/extrefs.
It's based on the Time-HiRes build code rather than cflags.SH\, but does fail if I add a static function referencing Perl_croak_nocontext to inline.h.
Tested locally on Win32\, cygwin\, Linux.
Thank you for writing this test. Unfortunately\, it fails on Solaris 11 with Sun's compiler:
porting/extrefs.t .. 1..1 cccmd = cc -o temp -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV -I.. temp.c Undefined first referenced symbol in file Perl_mg_size temp.o Perl__is_utf8_perl_idstart temp.o PL_charclass temp.o Perl_sv_free2 temp.o Perl__is_utf8_FOO temp.o ld: fatal: symbol referencing errors. No output written to temp not ok 1 # Failed test 1 - at porting/extrefs.t line 29 Failed 1/1 subtests
It failed on my Solaris smoke tester too:
http://www.nntp.perl.org/group/perl.daily-build.reports/2013/04/msg140448.html
which uses the Solaris compiler.
This also means that the base bug isn't actually fixed - while S_croak_memory_wrap() made the problem more visible\, it was present before that.
I had originally hoped that adding static inline functions would allow us to clean up some of the complicated duplicated macros (especially ones that have different forms for gcc) and simplify the source. Now I'm not so sure. I'm afraid I don't have any proposal to offer at the moment\, but I hope someone else will think of something.
I wonder if it's realistic to use perl's header files without using perl's library.
This is still a regression though.
Perhaps the inline.h header could be reverted for 5.18 with a notice for an upcoming change\, and reinstated in early 5.19.
Tony
On Wed\, 17 Apr 2013\, Tony Cook via RT wrote:
On Wed\, Apr 17\, 2013 at 09:17:17AM -0400\, Andy Dougherty wrote:
It failed on my Solaris smoke tester too:
http://www.nntp.perl.org/group/perl.daily-build.reports/2013/04/msg140448.html
which uses the Solaris compiler.
This also means that the base bug isn't actually fixed - while S_croak_memory_wrap() made the problem more visible\, it was present before that.
I had originally hoped that adding static inline functions would allow us to clean up some of the complicated duplicated macros (especially ones that have different forms for gcc) and simplify the source. Now I'm not so sure. I'm afraid I don't have any proposal to offer at the moment\, but I hope someone else will think of something.
I wonder if it's realistic to use perl's header files without using perl's library.
This is still a regression though.
Perhaps the inline.h header could be reverted for 5.18 with a notice for an upcoming change\, and reinstated in early 5.19.
I suspect that would be a big change too. I haven't had time to think it through at all carefully\, or to try it out and see what it might actually look like.
The following untested workaround patch might at least let us kick the can down the road a little. If we do nothing else\, we should probably at least do something like this.
Andy Dougherty doughera@lafayette.edu
On Wed\, Apr 24\, 2013 at 05:45:14PM -0400\, Andy Dougherty wrote:
On Wed\, 17 Apr 2013\, Tony Cook via RT wrote:
On Wed\, Apr 17\, 2013 at 09:17:17AM -0400\, Andy Dougherty wrote:
It failed on my Solaris smoke tester too:
http://www.nntp.perl.org/group/perl.daily-build.reports/2013/04/msg140448.html
which uses the Solaris compiler.
This also means that the base bug isn't actually fixed - while S_croak_memory_wrap() made the problem more visible\, it was present before that.
Yes:
~/Perl/perl/Porting/bisect.pl --target perl --start v5.16.0 -- sh -c './miniperl -Ilib make_ext.pl MAKE=make Time::HiRes; grep TIME_HIRES_CLOCK cpan/Time-HiRes/xdefine'
...
HEAD is now at 75e16a4 Use fast SvREFCNT_dec for non-GCC bad - non-zero exit from sh -c ./miniperl -Ilib make_ext.pl MAKE=make Time::HiRes; grep TIME_HIRES_CLOCK cpan/Time-HiRes/xdefine 75e16a44f58a9b54834e043a988a36289179c4ab is the first bad commit commit 75e16a44f58a9b54834e043a988a36289179c4ab Author: Father Chrysostomos \sprout@​cpan\.org Date: Sat Aug 18 12:39:40 2012 -0700
Use fast SvREFCNT_dec for non-GCC
:100644 100644 cdcaf04a8f35a302f18c85b8a7c81da35794ab15 798b493e216e456864c0c69fcefbfae83f879b4f M inline.h :100644 100644 970d03e85d6f16b6963511c6fb6df6ee041c480f ab0a0fdb6200ce37f2990c79893c63ddd5a107d1 M sv.h bisect run success That took 4163 seconds
That's the first commit that adds a static inline function definition which contains a reference to a global symbol. Which (of course) is exactly the sort of thing we *want* to use static inline functions for.
I wonder if it's realistic to use perl's header files without using perl's library.
There seem to be at least 3 use cases.
0) cflags.SH probing to work out what flags are valid. *before* building the perl library 1) probing\, where you actually want to run the code. 2) getting various information from the compiler about the headers\, prior to the main build (not yet used\, but I have a branch where I was using this to get the structure sizes)
Note that for "probing"\, you actually have the perl library somewhere. So it's viable to "fix" the probe by linking the perl library. But I think that it makes it more complex.
This is still a regression though.
Perhaps the inline.h header could be reverted for 5.18 with a notice for an upcoming change\, and reinstated in early 5.19.
I suspect that would be a big change too. I haven't had time to think it through at all carefully\, or to try it out and see what it might actually look like.
I fear that it's a big change.
The following untested workaround patch might at least let us kick the can down the road a little. If we do nothing else\, we should probably at least do something like this.
diff --git a/cpan/Time-HiRes/Makefile.PL b/cpan/Time-HiRes/Makefile.PL index 6f6a790..a0f9a01 100644 --- a/cpan/Time-HiRes/Makefile.PL +++ b/cpan/Time-HiRes/Makefile.PL @@ -115\,7 +115\,7 @@ __EOD__ } }
- my $ccflags = $Config{'ccflags'} . ' ' . "-I$COREincdir"; + my $ccflags = $Config{'ccflags'} . ' ' . $Config{'optimize'} . ' ' . "-I$COREincdir";
This\, however\, doesn't work if your build doesn't have the optimiser enabled.
The upshot is that even with this patch\, you end up with different runtime behaviour for the same module depending on whether the probing code happened to be run on a Perl with optimisation configured. Which feels like horrible action at a distance.
I can't see a way to have everything. ie
1) static inline functions to replace macros
combined with
2) defaulting to use them
3) not screwing up the "traditional" use without linking
I think that the least worst option is to keep (1) and (2)\, and force (3) to work by adding a define that disables inclusion of "inline.h" Of course\, that means that you can't *use* anything from it. But as all it contains are functions *declarations* that are of no use without data structures initialised from the perl library\, it's no loss.
Hence\, the attached patch\, which adds PERL_NO_INLINE_FUNCTIONS for that purpose. I've test appended patch on Solaris and HP-UX.
Without it\, at the tip of Tony's branch (or in blead):
$ cat cpan/Time-HiRes/xdefine -DTIME_HIRES_NANOSLEEP
With it:
$ cat cpan/Time-HiRes/xdefine -DTIME_HIRES_NANOSLEEP -DTIME_HIRES_CLOCK_GETTIME -DTIME_HIRES_CLOCK_GETRES -DTIME_HIRES_CLOCK
which is the same as v5.16.0: $ cat cpan/Time-HiRes/xdefine -DTIME_HIRES_NANOSLEEP -DTIME_HIRES_CLOCK_GETTIME -DTIME_HIRES_CLOCK_GETRES -DTIME_HIRES_CLOCK
Note that on both platforms static inline is real:
$ grep ^optimize config.sh optimize='-g' $ grep static_inline config.sh d_static_inline='define' perl_static_inline='static inline' $ grep ^ccversion config.sh ccversion='Sun C 5.12 SunOS_i386 2011/11/16'
$ grep ^optimize config.sh optimize='-g' $ grep static_inline config.sh d_static_inline='define' perl_static_inline='static __inline' $ grep ^ccversion config.sh ccversion='B.11.11.22'
so it's not some messy artefact of Configure faking "static inline" by using static.
Having had a big dig around CPAN\, I think that there are only 3 (possibly 4) modules where this matters.
Time::HiRes BSD::Resource (which is also by Jarkko\, so has the identical probe code) C::DynaLib (where the probe fails\, but the default works on x86_64)
and possibly Digest::MD5 and its copy-paste-edit variant. "Possibly"\, because it seems to skip the probe if $Config{d_u32align} exists\, and I think that that's now present everywhere.
So\, in terms of least worst\, I'm wondering if this is the way to go. Declare that the new black is "define PERL_NO_INLINE_FUNCTIONS if you need to use the perl headers but not link with the perl library"\, and submit patches to the 0.02% or so of CPAN that needs it.
Nicholas Clark
PS Note that patch hasn't touched cflags.SH - it's not "finished"
From eb4e33350076afce74a53d559559640b40a9166e Mon Sep 17 00:00:00 2001 From: Nicholas Clark \nick@​ccl4\.org Date: Fri\, 26 Apr 2013 01:25:56 +1000 Subject: [PATCH] Botherit
cpan/Time-HiRes/Makefile.PL | 3 ++- perl.h | 13 +++++++++++-- t/porting/extrefs.t | 6 ++++-- 3 files changed\, 17 insertions(+)\, 5 deletions(-)
On 04/25/2013 01:14 PM\, Nicholas Clark wrote:
I can't see a way to have everything. ie
1) static inline functions to replace macros
combined with
2) defaulting to use them
3) not screwing up the "traditional" use without linking
I think that the least worst option is to keep (1) and (2)\, and force (3) to work by adding a define that disables inclusion of "inline.h"
This sounds sensible to me
On Thu\, Apr 25\, 2013 at 03:23:31PM -0600\, Karl Williamson wrote:
On 04/25/2013 01:14 PM\, Nicholas Clark wrote:
I can't see a way to have everything. ie
1) static inline functions to replace macros
combined with
2) defaulting to use them
3) not screwing up the "traditional" use without linking
I think that the least worst option is to keep (1) and (2)\, and force (3) to work by adding a define that disables inclusion of "inline.h"
This sounds sensible to me
I've pushed this\, and Tony's test case as smoke-me/nicholas/extrefs
I think that if there aren't any problems\, we should merge this for v5.18.0 and submit patches for the 3 CPAN modules that need tweaking post v5.16.0
It actually works well enough that this commit could be reverted:
commit 43387ee1abcd83c3c7586b7f7aa86e838d239aac Author: Andy Dougherty \doughera@​lafayette\.edu Date: Wed Mar 27 15:54:05 2013 -0400
Remove the non-inline function S_croak_memory_wrap from inline.h.
This appears to resolve these three related tickets:
[perl #116989] S_croak_memory_wrap breaks gcc warning flags detection
[perl #117319] Can't include perl.h without linking to libperl
[perl #117331] Time::HiRes::clock_gettime not implemented on Linux (regression?)
This patch changes S_croak_memory_wrap from a static (but not inline)
function into an ordinary exported function Perl_croak_memory_wrap.
This has the advantage of allowing programs (particuarly probes\, such
as in cflags.SH and Time::HiRes) to include perl.h without linking
against libperl. Since it is not a static function defined within each
compilation unit\, the optimizer can no longer remove it when it's not
needed or inline it as needed. This likely negates some of the savings
that motivated the original commit 380f764c1ead36fe3602184804292711.
However\, calling the simpler function Perl_croak_memory_wrap() still
does take less set-up than the previous version\, so it may still be a
slight win. Specific cross-platform measurements are welcome.
I don't think that we should do it before 5.18.0\, but it now seems to be an option for 5.19.early.
Nicholas Clark
On Fri\, 26 Apr 2013\, Nicholas Clark via RT wrote:
On Thu\, Apr 25\, 2013 at 03:23:31PM -0600\, Karl Williamson wrote:
On 04/25/2013 01:14 PM\, Nicholas Clark wrote:
I can't see a way to have everything. ie
1) static inline functions to replace macros
combined with
2) defaulting to use them
3) not screwing up the "traditional" use without linking
I think that the least worst option is to keep (1) and (2)\, and force (3) to work by adding a define that disables inclusion of "inline.h"
This sounds sensible to me
I've pushed this\, and Tony's test case as smoke-me/nicholas/extrefs
I think that if there aren't any problems\, we should merge this for v5.18.0 and submit patches for the 3 CPAN modules that need tweaking post v5.16.0
I still haven't had time to reflect on this\, but it sounds like you've done so. I do agree this issue should be resolved for v5.18.0.
Since the define is a no-op right now\, CPAN modules can actually be patched now\, so they will continue to work seamlessly.
It actually works well enough that this commit could be reverted:
commit 43387ee1abcd83c3c7586b7f7aa86e838d239aac Author: Andy Dougherty \doughera@​lafayette\.edu Date: Wed Mar 27 15:54:05 2013 -0400
Remove the non\-inline function S\_croak\_memory\_wrap from inline\.h\. This appears to resolve these three related tickets​: \[perl \#116989\] S\_croak\_memory\_wrap breaks gcc warning flags detection \[perl \#117319\] Can't include perl\.h without linking to libperl \[perl \#117331\] Time​::HiRes​::clock\_gettime not implemented on Linux \(regression?\)
I don't think that we should do it before 5.18.0\, but it now seems to be an option for 5.19.early.
That was a "get-something-working-now" patch based on an incomplete understanding of the scope of the issue\, so reverting makes sense. On the other hand\, I never did get a chance to look deeply enough at the generated code to assess where it was best to put that type of function\, so I don't have a strong opinion either way.
-- Andy Dougherty doughera@lafayette.edu
On Fri Apr 26 08:13:41 2013\, nicholas wrote:
I've pushed this\, and Tony's test case as smoke-me/nicholas/extrefs
I don't see many smoke results on this\, sadly\, but I think we should land it unless there is positive evidence for a negative impact\, and ASAP. In other words\, let's merge it unless somebody shows\, "right now\," that it's no good.
-- rjbs
On Tue\, Apr 30\, 2013 at 03:14:10PM -0700\, Ricardo SIGNES via RT wrote:
On Fri Apr 26 08:13:41 2013\, nicholas wrote:
I've pushed this\, and Tony's test case as smoke-me/nicholas/extrefs
I don't see many smoke results on this\, sadly\, but I think we should land it unless there is positive evidence for a negative impact\, and ASAP. In other words\, let's merge it unless somebody shows\, "right now\," that it's no good.
There were smoke results for the previous iteration\, which showed that everything was happy except for *Darwin*'s flavour of g++ 4.2.1\, which objected to using "-ofilename"\, petulantly demanding a space in between. (The FreeBSD g++ 4.2.1 is happy with or without a space)
There are now smoke results for this iteration. Everything is happy with this test\, so I've merged the branch and pushed it to blead.
I haven't submitted patches to the 3 modules on CPAN that are affected. Nor have I documented the change in perldelta\, because it looks like the "current" pod/perldelta.pod is for the released v5.17.11
Nicholas Clark
Nicholas Clark writes:
Nor have I documented the change in perldelta\, because it looks like the "current" pod/perldelta.pod is for the released v5.17.11
I think you want the rjbs/perldelta-5.18 branch.
Smylers -- Stop drug companies hiding negative research results. Sign the AllTrials petition to get all clinical research results published. Read more: http://www.alltrials.net/blog/the-alltrials-campaign/
On Fri\, May 03\, 2013 at 01:35:39PM +0100\, Smylers wrote:
Nicholas Clark writes:
Nor have I documented the change in perldelta\, because it looks like the "current" pod/perldelta.pod is for the released v5.17.11
I think you want the rjbs/perldelta-5.18 branch.
Yes\, but in turn I think that that branch wants to appear in blead first.
Nicholas Clark
On Fri May 03 05:39:14 2013\, nicholas wrote:
On Fri\, May 03\, 2013 at 01:35:39PM +0100\, Smylers wrote:
I think you want the rjbs/perldelta-5.18 branch.
Yes\, but in turn I think that that branch wants to appear in blead first.
I've merged that branch. The delta is still in Porting until\, probably\, tomorrow. Maybe Tuesday.
Please feel free to edit it before then if you like.
Meanwhile\, marking this not-blocking.
-- rjbs
On Fri May 03 05:39:14 2013\, nicholas wrote:
On Fri\, May 03\, 2013 at 01:35:39PM +0100\, Smylers wrote:
Nicholas Clark writes:
Nor have I documented the change in perldelta\, because it looks like the "current" pod/perldelta.pod is for the released v5.17.11
I think you want the rjbs/perldelta-5.18 branch.
Yes\, but in turn I think that that branch wants to appear in blead first.
I'm pretty sure this ticket can be closed now.
I'll close it in a few days unless someone objects.
Tony
On Fri Apr 26 08:13:41 2013\, nicholas wrote:
On Thu\, Apr 25\, 2013 at 03:23:31PM -0600\, Karl Williamson wrote:
On 04/25/2013 01:14 PM\, Nicholas Clark wrote:
I can't see a way to have everything. ie
1) static inline functions to replace macros
combined with
2) defaulting to use them
3) not screwing up the "traditional" use without linking
I think that the least worst option is to keep (1) and (2)\, and force (3) to work by adding a define that disables inclusion of "inline.h"
This sounds sensible to me
I've pushed this\, and Tony's test case as smoke-me/nicholas/extrefs
I think that if there aren't any problems\, we should merge this for v5.18.0 and submit patches for the 3 CPAN modules that need tweaking post v5.16.0
It actually works well enough that this commit could be reverted:
commit 43387ee1abcd83c3c7586b7f7aa86e838d239aac Author: Andy Dougherty \doughera@​lafayette\.edu Date: Wed Mar 27 15:54:05 2013 -0400
Remove the non\-inline function S\_croak\_memory\_wrap from inline\.h\.
Should it be reverted?
I have no real opinion either way\, but either we could revert it and close this ticket\, or just close this ticket.
Tony
On Sun Jul 14 21:35:38 2013\, tonyc wrote:
Should it be reverted?
I have no real opinion either way\, but either we could revert it and close this ticket\, or just close this ticket.
Tony
Commit message at http://perl5.git.perl.org/perl.git/commit/28fbb451174e1613d5b90a4961cfb629936bea55 needs to be fixed before it goes in blead. 380f764c1ead36fe3602184804292711 is not a valid sha1\, the correct one is f019c49e380f764c1ead36fe3602184804292711\, notice 380f... is part of it. I mentioned this on p5p IRC a few days ago\, but I'm putting it here in case TonyC forgets.
-- bulk88 ~ bulk88 at hotmail.com
On Sun\, Jul 14\, 2013 at 09:35:38PM -0700\, Tony Cook via RT wrote:
On Fri Apr 26 08:13:41 2013\, nicholas wrote:
It actually works well enough that this commit could be reverted:
commit 43387ee1abcd83c3c7586b7f7aa86e838d239aac Author: Andy Dougherty \doughera@​lafayette\.edu Date: Wed Mar 27 15:54:05 2013 -0400
Remove the non\-inline function S\_croak\_memory\_wrap from inline\.h\.
Should it be reverted?
I have no real opinion either way\, but either we could revert it and close this ticket\, or just close this ticket.
As we now have the mechanisms in place to make a non-inline static function viable\, and this non-inline static function improved the generated code\, I think that we should put it back. (Assuming\, of course\, that I'm right and it doesn't throw up any new problems.)
Where "put it back" is:
On Tue\, Jul 16\, 2013 at 03:35:28PM -0700\, bulk88 via RT wrote:
Commit message at http://perl5.git.perl.org/perl.git/commit/28fbb451174e1613d5b90a4961cfb629936bea55 needs to be fixed before it goes in blead. 380f764c1ead36fe3602184804292711 is not a valid sha1\, the correct one is f019c49e380f764c1ead36fe3602184804292711\, notice 380f... is part of it. I mentioned this on p5p IRC a few days ago\, but I'm putting it here in case TonyC forgets.
Nicholas Clark
On Tue Jul 16 15:35:28 2013\, bulk88 wrote:
On Sun Jul 14 21:35:38 2013\, tonyc wrote:
Should it be reverted?
I have no real opinion either way\, but either we could revert it and close this ticket\, or just close this ticket.
Tony
Commit message at
http://perl5.git.perl.org/perl.git/commit/28fbb451174e1613d5b90a4961cfb629936bea55 needs to be fixed before it goes in blead. 380f764c1ead36fe3602184804292711 is not a valid sha1\, the correct one is f019c49e380f764c1ead36fe3602184804292711\, notice 380f... is part of it. I mentioned this on p5p IRC a few days ago\, but I'm putting it here in case TonyC forgets.
Applied with the SHA fix.
Tony
@tonycoz - Status changed from 'open' to 'resolved'
Migrated from rt.perl.org#116989 (status was 'resolved')
Searchable as RT116989$