Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

S_croak_memory_wrap breaks gcc warning flags detection #12824

Closed
p5pRT opened this issue Feb 28, 2013 · 47 comments
Closed

S_croak_memory_wrap breaks gcc warning flags detection #12824

p5pRT opened this issue Feb 28, 2013 · 47 comments

Comments

@p5pRT
Copy link

p5pRT commented Feb 28, 2013

Migrated from rt.perl.org#116989 (status was 'resolved')

Searchable as RT116989$

@p5pRT
Copy link
Author

p5pRT commented Feb 28, 2013

From @doughera88

Created by @doughera88

This commit​:

commit f019c49
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.)

Perl Info

Flags:
    category=install
    severity=medium

Site configuration information for perl 5.17.10:

Configured by doughera at Thu Feb 28 08:20:41 EST 2013

Summary of my perl5 (revision 5 version 17 subversion 10) configuration:
  Commit id: 41191e557c536be3754384dee54e7700ca3df256
  Platform:
    osname=linux, osvers=3.2.0-4-amd64, archname=x86_64-linux
    uname='linux ooo 3.2.0-4-amd64 #1 smp debian 3.2.35-2 x86_64 gnulinux '
    config_args='-Dusedevel -Dprefix=/opt/perl -des'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.7.2', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
    libs=-lnsl -ldl -lm -lcrypt -lutil -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.13'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'


Characteristics of this binary (from libperl): 
  Compile-time options: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV
                        PERL_MALLOC_WRAP PERL_NEW_COPY_ON_WRITE
                        PERL_PRESERVE_IVUV PERL_USE_DEVEL USE_64_BIT_ALL
                        USE_64_BIT_INT USE_LARGE_FILES USE_LOCALE
                        USE_LOCALE_COLLATE USE_LOCALE_CTYPE
                        USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
  Built under linux
  Compiled at Feb 28 2013 08:18:50
  @INC:
    lib
    /opt/perl/lib/site_perl/5.17.10/x86_64-linux
    /opt/perl/lib/site_perl/5.17.10
    /opt/perl/lib/5.17.10/x86_64-linux
    /opt/perl/lib/5.17.10
    /opt/perl/lib/site_perl
    .

@p5pRT
Copy link
Author

p5pRT commented Feb 28, 2013

From @nwc10

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

@p5pRT
Copy link
Author

p5pRT commented Feb 28, 2013

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

@p5pRT
Copy link
Author

p5pRT commented Feb 28, 2013

From @doughera88

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.)

Inline Patch
diff --git a/cflags.SH b/cflags.SH
index 899c465..9efd503 100755
--- a/cflags.SH
+++ b/cflags.SH
@@ -43,6 +43,9 @@ esac
 
 cat >_cflags.c <<__EOT__
 #include "EXTERN.h"
+/* Avoid perl's inline.h file, which needs to link to other files not
+  yet compiled. */
+#define PERL_INLINE_H 1 
 #include "perl.h"
 /* The stdio.h, errno.h, and setjmp.h should be there in any ANSI C89. */
 #include <stdio.h>
diff --git a/inline.h b/inline.h
index 6b5f93c..697f197 100644
--- a/inline.h
+++ b/inline.h
@@ -12,6 +12,9 @@
  * Each section names the header file that the functions "belong" to.
  */
 
+#ifndef PERL_INLINE_H 
+#define PERL_INLINE_H 1
+
 /* ------------------------------- av.h ------------------------------- */
 
 PERL_STATIC_INLINE I32
@@ -141,6 +144,7 @@ S_sv_or_pv_pos_u2b(pTHX_ SV *sv, const char *pv, STRLEN pos, STRLEN *lenp)
 #pragma clang diagnostic push
 #pragma clang diagnostic ignored "-Wunused-function"
 #endif
+/* Deliberately not inline.  See f019c49e. */
 static void
 S_croak_memory_wrap(void)
 {
@@ -170,3 +174,4 @@ S_isALNUM_lazy(pTHX_ const char* p)
 
     return isALNUM_lazy_if(p,1);
 }
+#endif /* PERL_INLINE_H */


-- 

  Andy Dougherty doughera@​lafayette.edu

@p5pRT
Copy link
Author

p5pRT commented Feb 28, 2013

From @nwc10

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

@p5pRT
Copy link
Author

p5pRT commented Feb 28, 2013

From @bulk88

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

@p5pRT
Copy link
Author

p5pRT commented Feb 28, 2013

From @doughera88

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

@p5pRT
Copy link
Author

p5pRT commented Mar 24, 2013

From @ilmari

Created by @ilmari

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$

Perl Info

Flags:
    category=core
    severity=high

Site configuration information for perl 5.17.10:

Configured by ilmari at Sat Mar 23 15:33:12 GMT 2013.

Summary of my perl5 (revision 5 version 17 subversion 10) configuration:
   
  Platform:
    osname=linux, osvers=3.5.0-25-generic, archname=x86_64-linux
    uname='linux nurket 3.5.0-25-generic #38-ubuntu smp mon feb 18 23:27:42 utc 2013 x86_64 x86_64 x86_64 gnulinux '
    config_args='-de -Dprefix=/home/ilmari/perl5/perlbrew/perls/perl-5.17.10 -Dusedevel -Aeval:scriptdir=/home/ilmari/perl5/perlbrew/perls/perl-5.17.10/bin'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.7.2', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
    libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.15'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'

Locally applied patches:
    


@INC for perl 5.17.10:
    /home/ilmari/perl5/perlbrew/perls/perl-5.17.10/lib/site_perl/5.17.10/x86_64-linux
    /home/ilmari/perl5/perlbrew/perls/perl-5.17.10/lib/site_perl/5.17.10
    /home/ilmari/perl5/perlbrew/perls/perl-5.17.10/lib/5.17.10/x86_64-linux
    /home/ilmari/perl5/perlbrew/perls/perl-5.17.10/lib/5.17.10
    .


Environment for perl 5.17.10:
    HOME=/home/ilmari
    LANG=en_GB.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/ilmari/perl5/perlbrew/bin:/home/ilmari/perl5/perlbrew/perls/perl-5.17.10/bin:/home/ilmari/perls/v5.12.2/bin:/home/ilmari/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
    PERLBREW_BASHRC_VERSION=0.60
    PERLBREW_HOME=/home/ilmari/.perlbrew
    PERLBREW_MANPATH=/home/ilmari/perl5/perlbrew/perls/perl-5.17.10/man
    PERLBREW_PATH=/home/ilmari/perl5/perlbrew/bin:/home/ilmari/perl5/perlbrew/perls/perl-5.17.10/bin
    PERLBREW_PERL=perl-5.17.10
    PERLBREW_ROOT=/home/ilmari/perl5/perlbrew
    PERLBREW_VERSION=0.60
    PERL_AUTOINSTALL_PREFER_CPAN=1
    PERL_BADLANG (unset)
    PERL_MM_PREFER_CPAN=1
    PERL_MM_USE_DEFAULT=1
    SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Mar 24, 2013

From @ilmari

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

@p5pRT
Copy link
Author

p5pRT commented Mar 24, 2013

From @bulk88

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

@p5pRT
Copy link
Author

p5pRT commented Mar 24, 2013

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

@p5pRT
Copy link
Author

p5pRT commented Mar 24, 2013

From @bulk88

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

@p5pRT
Copy link
Author

p5pRT commented Mar 25, 2013

From @dmcbride

Created by @dmcbride

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

Perl Info

Flags:
    category=library
    severity=high
    module=Time::HiRes

Site configuration information for perl 5.17.10:

Configured by root at Sun Mar 24 22:48:40 MDT 2013.

Summary of my perl5 (revision 5 version 17 subversion 10) configuration:
   
  Platform:
    osname=linux, osvers=3.7.10-gentoo, archname=x86_64-linux-thread-multi
    uname='linux naboo 3.7.10-gentoo #1 smp sat mar 2 07:34:20 mst 2013 x86_64 intel(r) core(tm) i7 cpu 930 @ 2.80ghz genuineintel gnulinux '
    config_args='-desr -Duse64bitall -Duselongdoubles -Dusethreads -Dusedevel -Dperladmin=dmcbride@cpan.org -Dprefix=/opt/myperl/5.17.10'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector'
    ccversion='', gccversion='4.6.3', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib/../lib64 /usr/lib/../lib64 /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64
    libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc -lgdbm_compat
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=/lib/libc-2.15.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.15'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'

Locally applied patches:
    


@INC for perl 5.17.10:
    /opt/myperl/5.17.10/lib/site_perl/5.17.10/x86_64-linux-thread-multi
    /opt/myperl/5.17.10/lib/site_perl/5.17.10
    /opt/myperl/5.17.10/lib/5.17.10/x86_64-linux-thread-multi
    /opt/myperl/5.17.10/lib/5.17.10
    .


Environment for perl 5.17.10:
    HOME=/home/dmcbride
    LANG=en_US.utf8
    LANGUAGE=
    LC_ALL=en_US.utf8
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/dmcbride/bin:/usr/lib/distcc/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3:/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/gcc-bin/4.6.3:/opt/android-sdk-update-manager/tools:/opt/android-sdk-update-manager/platform-tools:/opt/nvidia-cg-toolkit/bin:/share/cvs/bin:/usr/local/bin:/usr/games/bin:/share/bin:/share/darin/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Mar 25, 2013

From @ilmari

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

@p5pRT
Copy link
Author

p5pRT commented Mar 25, 2013

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

@p5pRT
Copy link
Author

p5pRT commented Mar 25, 2013

From @nwc10

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

@p5pRT
Copy link
Author

p5pRT commented Mar 27, 2013

From @tonycoz

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

@p5pRT
Copy link
Author

p5pRT commented Mar 27, 2013

From @doughera88

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

@p5pRT
Copy link
Author

p5pRT commented Mar 28, 2013

From @bulk88

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

@p5pRT
Copy link
Author

p5pRT commented Mar 28, 2013

From @jkeenan

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.

@p5pRT
Copy link
Author

p5pRT commented Mar 28, 2013

From @jkeenan

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).

@p5pRT
Copy link
Author

p5pRT commented Mar 28, 2013

From @bulk88

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

@p5pRT
Copy link
Author

p5pRT commented Mar 28, 2013

From @doughera88

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 43387ee

  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

@p5pRT
Copy link
Author

p5pRT commented Mar 28, 2013

From @bulk88

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

@p5pRT
Copy link
Author

p5pRT commented Mar 29, 2013

From @bulk88

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

@p5pRT
Copy link
Author

p5pRT commented Mar 29, 2013

From @doughera88

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

@p5pRT
Copy link
Author

p5pRT commented Mar 29, 2013

From @bulk88

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

@p5pRT
Copy link
Author

p5pRT commented Apr 3, 2013

From @doughera88

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

@p5pRT
Copy link
Author

p5pRT commented Apr 14, 2013

From @tonycoz

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

@p5pRT
Copy link
Author

p5pRT commented Apr 17, 2013

From @doughera88

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

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2013

From @tonycoz

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

@p5pRT
Copy link
Author

p5pRT commented Apr 24, 2013

From @doughera88

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.

Inline Patch
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";
 
 	if ($^O eq 'VMS') {
             $cccmd = "$Config{'cc'} /include=($COREincdir) $tmp.c";
diff --git a/t/porting/extrefs.t b/t/porting/extrefs.t
index 42045c2..a990639 100644
--- a/t/porting/extrefs.t
+++ b/t/porting/extrefs.t
@@ -66,7 +66,7 @@ sub try_compile_and_link {
 
 	my $COREincdir = File::Spec->catdir(File::Spec->updir);
 
-	my $ccflags = $Config{'ccflags'} . ' ' . "-I$COREincdir";
+	my $ccflags = $Config{'ccflags'} . ' ' . $Config{'optimize'} . ' ' . "-I$COREincdir";
 
 	if ($^O eq "MSWin32") {
 	    $ccflags .= " -I../win32 -I../win32/include";


-- 

  Andy Dougherty doughera@​lafayette.edu

@p5pRT
Copy link
Author

p5pRT commented Apr 25, 2013

From @nwc10

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
75e16a4 is the first bad commit
commit 75e16a4
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(-)

Inline Patch
diff --git a/cpan/Time-HiRes/Makefile.PL b/cpan/Time-HiRes/Makefile.PL
index 6f6a790..f27439e 100644
--- a/cpan/Time-HiRes/Makefile.PL
+++ b/cpan/Time-HiRes/Makefile.PL
@@ -115,7 +115,8 @@ __EOD__
             }
         }
 
-	my $ccflags = $Config{'ccflags'} . ' ' . "-I$COREincdir";
+	my $ccflags = $Config{'ccflags'} . ' ' . "-I$COREincdir"
+	 . ' -DPERL_NO_INLINE_FUNCTIONS';
 
 	if ($^O eq 'VMS') {
             $cccmd = "$Config{'cc'} /include=($COREincdir) $tmp.c";
diff --git a/perl.h b/perl.h
index 5639f1c..f2a5b52 100644
--- a/perl.h
+++ b/perl.h
@@ -5239,8 +5239,17 @@ EXTCONST bool PL_valid_types_NV_set[];
 
 #endif
 
-/* Static inline funcs that depend on includes and declarations above */
-#include "inline.h"
+#ifndef PERL_NO_INLINE_FUNCTIONS
+/* Static inline funcs that depend on includes and declarations above.
+   Some of these reference functions in the perl object files, and some
+   compilers aren't smart enough to eliminate unused static inline functions,
+   so including this file in source code can cause link errors even if the
+   source code uses none of the functions. Hence including these can be be
+   suppressed by setting PERL_NO_INLINE_FUNCTIONS. Doing this will (obviously)
+   result in unworkable XS code, but permits simple probing code to continue
+   to work.  */
+#  include "inline.h"
+#endif
 
 #include "overload.h"
 
diff --git a/t/porting/extrefs.t b/t/porting/extrefs.t
index c19eb56..95c59b3 100644
--- a/t/porting/extrefs.t
+++ b/t/porting/extrefs.t
@@ -26,6 +26,8 @@ use Cwd;
 
 plan(tests => 1);
 
+my $VERBOSE = grep {/^-v$/} @ARGV;
+
 ok(try_compile_and_link(<<'CODE'));
 #include "EXTERN.h"
 #include "perl.h"
@@ -44,7 +46,6 @@ sub try_compile_and_link {
     my $ld_exeext = ($^O eq 'cygwin' || $^O eq 'MSWin32' ||
                  $^O eq 'os2' && $Config{ldflags} =~ /-Zexe\b/) ? '.exe' :
                 (($^O eq 'vos') ? $Config{exe_ext} : '');
-    my $VERBOSE = 0;
 
     my ($ok) = 0;
     my $tempdir = tempfile();
@@ -66,7 +67,8 @@ sub try_compile_and_link {
 
 	my $COREincdir = File::Spec->catdir(File::Spec->updir);
 
-	my $ccflags = $Config{'ccflags'} . ' ' . "-I$COREincdir";
+	my $ccflags = $Config{'ccflags'} . ' ' . "-I$COREincdir"
+	 . ' -DPERL_NO_INLINE_FUNCTIONS';
 
 	if ($^O eq "MSWin32") {
 	    $ccflags .= " -I../win32 -I../win32/include";
-- 
1.7.9.2

@p5pRT
Copy link
Author

p5pRT commented Apr 25, 2013

From @khwilliamson

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

@p5pRT
Copy link
Author

p5pRT commented Apr 26, 2013

From @nwc10

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 43387ee
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

@p5pRT
Copy link
Author

p5pRT commented Apr 26, 2013

From @doughera88

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 43387ee
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&#8203;:

    \[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&#8203;::HiRes&#8203;::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

@p5pRT
Copy link
Author

p5pRT commented Apr 30, 2013

From @rjbs

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

@p5pRT
Copy link
Author

p5pRT commented May 3, 2013

From @nwc10

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

@p5pRT
Copy link
Author

p5pRT commented May 3, 2013

From @Smylers

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/

@p5pRT
Copy link
Author

p5pRT commented May 3, 2013

From @nwc10

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

@p5pRT
Copy link
Author

p5pRT commented May 5, 2013

From @rjbs

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

@p5pRT
Copy link
Author

p5pRT commented Jul 5, 2013

From @tonycoz

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

@p5pRT
Copy link
Author

p5pRT commented Jul 15, 2013

From @tonycoz

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 43387ee
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

@p5pRT
Copy link
Author

p5pRT commented Jul 16, 2013

From @bulk88

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
f019c49, 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

@p5pRT
Copy link
Author

p5pRT commented Jul 17, 2013

From @nwc10

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 43387ee
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
f019c49, 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

@p5pRT
Copy link
Author

p5pRT commented Jul 24, 2013

From @tonycoz

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
f019c49, 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

@p5pRT
Copy link
Author

p5pRT commented Jul 24, 2013

@tonycoz - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant