develooper Front page | perl.perl5.porters | Postings from October 2014

Re: Any empty members in struct xpvcv AKA CV that an XSUB can use?

Thread Previous | Thread Next
From:
Andy Dougherty
Date:
October 24, 2014 11:06
Subject:
Re: Any empty members in struct xpvcv AKA CV that an XSUB can use?
Message ID:
20141024110533.GA27376@fractal.phys.lafayette.edu
On Wed, Oct 22, 2014 at 03:16:25PM -0400, bulk88 wrote:

> Must be 64 bit/void * sized. 

(Just a minor quibble, but I'm afraid I don't know exactly what you
mean here.  What if perl is compiled with 64-bit IVs, but (void *)
is only 32 bit?)

> Must be 64 bit/void * sized. What I am trying to do is stop
> ABI/linking problems, where Dynaloader loads a XS module compiled
> with 5.18 into a 5.20 process, or DEBUGGING vs no DEBUGGING or
> DEBUG_LEAKING_SCALARS vs no DEBUG_LEAKING_SCALARS. On Win32 unlike
> ELF, there is no global symbol table, so Perl/Dynaloader has no way
> to know if Dynaloader from 5.18 loads a XS module that links with
> 5.20, and both interps (5.18/5.20) happen to be in %PATH. 

On the other hand, on many systems it should be perfectly fine to load
an XS module compiled with 5.20.0 into a 5.20.1 process, provided both
were compiled with compatible Configure options.

I'm not opposed to extra safeguards, but the installation hierarchy is
supposed to automtically prevent this sort of mis-loading for the common
cases (e.g. 5.18 vs. 5.20, 64-bit vs 32-bit, debugging vs. non-debugging,
and threading).  I gather Windows installs things differently, but it
may be worthwhile to revisit what it is doing differently and why,
and whether that's where this problem should be addressed.

Still, for more unusual build options (such as DEBUG_LEAKING_SCALRS), it
definitely is the case that the installation hierarchy and XS apiversion
protection are indeed insufficient.  The usual advice is to install such
builds under a prefix where the regular build won't find them.  Some
extra protection for those cases wouldn't be inappropriate.

However, I confess I don't understand how what you are proposing would
address these problems, at least in the Linux world.

-- 
    Andy Dougherty		doughera@lafayette.edu


To fix
> this, i will have a dynaloder boot xsub get, then pass on a magic
> value that only the perl image that called
> pp_entersub/dl_install_xsub (probably latter) knows, so that
> Perl_xs_apiversion_bootcheck (or its successors) can use to make
> sure this instance of Perl_xs_apiversion_bootcheck is the same one
> that pp_entersub called. For PERL_IMPLICIT_CONTEXT builds, the
> "magic value" is aTHX/my_perl, then compare to dTHX/Perl_get_context
> value. Since in a no-PERL_IMPLICIT_CONTEXT build, the XSUB gets
> exactly 1 argument, CV * cv, so the magic value for
> no-PERL_IMPLICIT_CONTEXT has to be in arg cv for
> Perl_xs_apiversion_bootcheck to examine. I've picked "&PL_stack_sp"
> as the magic value for no-PERL_IMPLICIT_CONTEXT.
> 
> I could use the traditional XS_ANY but I dont feel perfectly safe
> taking it away from CPAN code (non-xsubpp based XS modules, or xs
> modules that aggregate multiple .xs files/.o files/multiple boot
> xsubs using custom code to present 1 boot xsub to the shared library
> system, and then calls all the other boot xsubs in the shared
> library). Changing a an XSUB's C proto to add another arg is
> impossible, so without arg my_perl, the magic value must be in arg
> cv. I could also use magic, but it seems too heavy weight vs finding
> another member in the CV body struct to unionize.
> 
> Attached is latest patch, in particular I want arg v_my_perl to be a
> CV * in the future on no-PERL_IMPLICIT_CONTEXT builds, and have
> &PL_stack_sp computed in dl_install_xsub on unthreaded perl, not in
> the XS DLL, since computing it in boot XSUB is useless since
> &PL_stack_sp in boot XSUB already links to the wrong interp if there
> happens to be a mixup and the test will pass even with interp
> version mixup.
> 
> I dont want this callstack ending with a SEGV anymore.
> 
> 	perl512.dll!Perl_safesysmalloc(unsigned int size=12)  Line 94 + 0xd
> bytes	C
>   	perl512.dll!Perl_sv_grow(interpreter * my_perl=0x01c45c34, sv * const
> sv=0x01ee8600, unsigned int newlen=1)  Line 1562 + 0x6 bytes	C
>   	perl512.dll!Perl_sv_setpvn(interpreter * my_perl=0x01c45c34, sv *
> const sv=0x01ee8600, const char * const ptr=0x02031748, const unsigned
> int len=0)  Line 4343 + 0x14 bytes	C
>   	perl512.dll!Perl_newSVpvn_flags(interpreter * my_perl=0x01c45c34,
> const char * const s=0x02031748, const unsigned int len=0, const
> unsigned long flags=524288)  Line 7711	C
>   	perl512.dll!S_mess_alloc(interpreter * my_perl=0x01c45c34)  Line 1055
> + 0x12 bytes	C
>   	perl512.dll!Perl_form(interpreter * my_perl=0x01c45c34, const char *
> pat=0x01f75f18, ...)  Line 1113 + 0xf bytes	C
>   	Win32.dll!boot_Win32(interpreter * my_perl=0x01ee046c, cv *
> cv=0x01e9bff4)  Line 2495 + 0x7f bytes	C
>   	perl519.dll!Perl_pp_entersub(interpreter * my_perl=0x01c466e8)
> Line 2763	C
>   	perl519.dll!Perl_runops_standard(interpreter * my_perl=0x01c45c34)
> Line 42 + 0x4 bytes	C
>   	perl519.dll!Perl_call_sv(interpreter * my_perl=0x01c45c34, sv *
> sv=0x01e79b8c, volatile long flags=13)  Line 2747 + 0xc bytes	C
>   	perl519.dll!Perl_call_list(interpreter * my_perl=0x01c45c34, long
> oldscope=8, av * paramList=0x01c6ec34)  Line 4843	C
>   	perl519.dll!S_process_special_blocks(interpreter *
> my_perl=0x00000000, long floor=0, const char * const
> fullname=0x01c795e0, gv * const gv=0x01dfc564, cv * const cv=0x01e79b8c)
>   Line 7932	C
>   	perl519.dll!Perl_newATTRSUB_flags(interpreter * my_perl=0x00000000,
> long floor=43, op * o=0x01e6a9d0, op * proto=0x00000000, void *
> attrs=0x2802c589, op * block=0x01e6a9f0, unsigned long flags=0)  Line
> 7894 + 0x16 bytes	C
>   	perl519.dll!Perl_newATTRSUB(interpreter * my_perl=0x01c45c34, long
> floor=43, op * o=0x01e6a9d0, op * proto=0x00000000, op *
> attrs=0x00000000, op * block=0x01e6a9f0)  Line 7569 + 0x19 bytes	C
>   	perl519.dll!Perl_utilize(interpreter * my_perl=0x00000000, int
> aver=1, long floor=43, op * version=0x01e83744, op * idop=0x01e92f54, op
> * arg=0x01e6f864)  Line 5317 + 0x7e bytes	C
>   	perl519.dll!Perl_vload_module(interpreter * my_perl=0x01e92f54,
> unsigned long flags=2, sv * name=0x01caf56c, sv * ver=0x01e83744, char *
> * args=0x002df984)  Line 5463 + 0x23 bytes	C
>   	perl519.dll!Perl_load_module(interpreter * my_perl=0x01c45c34,
> unsigned long flags=2, sv * name=0x01caf56c, sv * ver=0x01e70154, ...)
> Line 5405 + 0x16 bytes	C
>   	perl519.dll!w32_CORE_all(interpreter * my_perl=0x01c45c34, cv *
> cv=0x01c4bb84)  Line 33 + 0x3c bytes	C
>   	perl519.dll!Perl_pp_entersub(interpreter * my_perl=0x01c4bb74)
> Line 2763	C
>   	perl519.dll!Perl_runops_standard(interpreter * my_perl=0x01c45c34)
> Line 42 + 0x4 bytes	C
>   	perl519.dll!Perl_call_sv(interpreter * my_perl=0x01c45c34, sv *
> sv=0x01e099b4, volatile long flags=13)  Line 2747 + 0xc bytes	C
>   	perl519.dll!Perl_call_list(interpreter * my_perl=0x01c45c34, long
> oldscope=1, av * paramList=0x01d39f8c)  Line 4843	C
>   	perl519.dll!perl_run(interpreter * my_perl=0x01c45c34)  Line 2359 +
> 0x12 bytes	C
>   	perl519.dll!RunPerl(int argc=3, char * * argv=0x01c45be0, char * *
> env=0x01c440e0)  Line 270 + 0x6 bytes	C++
>   	perl.exe!__tmainCRTStartup()  Line 582 + 0x17 bytes	C
>   	kernel32.dll!_BaseProcessStart@4()  + 0x28 bytes	

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About