Navigation Menu

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

[PATCH] const vtables in win32/perlhost.h #14994

Closed
p5pRT opened this issue Oct 19, 2015 · 7 comments
Closed

[PATCH] const vtables in win32/perlhost.h #14994

p5pRT opened this issue Oct 19, 2015 · 7 comments

Comments

@p5pRT
Copy link

p5pRT commented Oct 19, 2015

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

Searchable as RT126402$

@p5pRT
Copy link
Author

p5pRT commented Oct 19, 2015

From @bulk88

See attached patch.
 

@p5pRT
Copy link
Author

p5pRT commented Oct 19, 2015

From @bulk88

0001-const-vtables-in-win32-perlhost.h.patch
From 7d9ee70a4161735071dca9784de2fc56dc7aedbb Mon Sep 17 00:00:00 2001
From: Daniel Dragan <bulk88@hotmail.com>
Date: Mon, 19 Oct 2015 17:47:16 -0400
Subject: [PATCH] const vtables in win32/perlhost.h

This allows some more memory to be shared between 2 perl processes since
it is const. VC 2013 32b build, before Virtual Size of perl523.dll
sections, .rdata 0x3DE00 bytes .data 0x1B90, after .rdata 0x3E140
.data 0x18B0.
---
 win32/perlhost.h | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/win32/perlhost.h b/win32/perlhost.h
index ce31f69..9963319 100644
--- a/win32/perlhost.h
+++ b/win32/perlhost.h
@@ -329,7 +329,7 @@ PerlMemIsLocked(struct IPerlMem* piPerl)
     return IPERL2HOST(piPerl)->IsLocked();
 }
 
-struct IPerlMem perlMem =
+const struct IPerlMem perlMem =
 {
     PerlMemMalloc,
     PerlMemRealloc,
@@ -383,7 +383,7 @@ PerlMemSharedIsLocked(struct IPerlMem* piPerl)
     return IPERL2HOST(piPerl)->IsLockedShared();
 }
 
-struct IPerlMem perlMemShared =
+const struct IPerlMem perlMemShared =
 {
     PerlMemSharedMalloc,
     PerlMemSharedRealloc,
@@ -437,7 +437,7 @@ PerlMemParseIsLocked(struct IPerlMem* piPerl)
     return IPERL2HOST(piPerl)->IsLockedParse();
 }
 
-struct IPerlMem perlMemParse =
+const struct IPerlMem perlMemParse =
 {
     PerlMemParseMalloc,
     PerlMemParseRealloc,
@@ -538,7 +538,7 @@ PerlEnvGetChildIO(struct IPerlEnv* piPerl, child_IO_table* ptr)
     win32_get_child_IO(ptr);
 }
 
-struct IPerlEnv perlEnv =
+const struct IPerlEnv perlEnv =
 {
     PerlEnvGetenv,
     PerlEnvPutenv,
@@ -866,7 +866,7 @@ PerlStdIOFdupopen(struct IPerlStdIO* piPerl, FILE* pf)
 #endif
 }
 
-struct IPerlStdIO perlStdIO =
+const struct IPerlStdIO perlStdIO =
 {
     PerlStdIOStdin,
     PerlStdIOStdout,
@@ -1077,7 +1077,7 @@ PerlLIOWrite(struct IPerlLIO* piPerl, int handle, const void *buffer, unsigned i
     return win32_write(handle, buffer, count);
 }
 
-struct IPerlLIO perlLIO =
+const struct IPerlLIO perlLIO =
 {
     PerlLIOAccess,
     PerlLIOChmod,
@@ -1178,7 +1178,7 @@ PerlDirMapPathW(struct IPerlDir* piPerl, const WCHAR* path)
     return IPERL2HOST(piPerl)->MapPathW(path);
 }
 
-struct IPerlDir perlDir =
+const struct IPerlDir perlDir =
 {
     PerlDirMakedir,
     PerlDirChdir,
@@ -1464,7 +1464,7 @@ PerlSockIoctlsocket(struct IPerlSock* piPerl, SOCKET s, long cmd, u_long *argp)
     return win32_ioctlsocket(s, cmd, argp);
 }
 
-struct IPerlSock perlSock =
+const struct IPerlSock perlSock =
 {
     PerlSockHtonl,
     PerlSockHtons,
@@ -1898,7 +1898,7 @@ PerlProcLastHost(struct IPerlProc* piPerl)
  return h->LastHost();
 }
 
-struct IPerlProc perlProc =
+const struct IPerlProc perlProc =
 {
     PerlProcAbort,
     PerlProcCrypt,
-- 
1.9.5.msysgit.1

@p5pRT
Copy link
Author

p5pRT commented Oct 20, 2015

From @bulk88

On Mon Oct 19 14​:51​:37 2015, bulk88 wrote​:

See attached patch.

I should have put this in the commit message.


It is not known for CPAN code to hook these vtables at runtime. Also on no-psuedofork or no thread builds of Win32 Perl, these vtables do not exist to be runtime hooked in the first place. Therefore consting them is not breaking API.

--
bulk88 ~ bulk88 at hotmail.com

@p5pRT
Copy link
Author

p5pRT commented Oct 20, 2015

From @tonycoz

On Mon Oct 19 17​:26​:43 2015, bulk88 wrote​:

On Mon Oct 19 14​:51​:37 2015, bulk88 wrote​:

See attached patch.

I should have put this in the commit message.
------------------------------------
It is not known for CPAN code to hook these vtables at runtime. Also
on no-psuedofork or no thread builds of Win32 Perl, these vtables do
not exist to be runtime hooked in the first place. Therefore consting
them is not breaking API.

Thanks applied as af2f850.

I suspect PerlEx used it (ActiveState's IIS plugin), but the interfaces all seem to make copies of the vtables rather than using them in place and pointers to the original vtables don't seem to be visible, so this patch is safe.

Tony

@p5pRT
Copy link
Author

p5pRT commented Oct 20, 2015

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

@p5pRT p5pRT closed this as completed Oct 20, 2015
@p5pRT
Copy link
Author

p5pRT commented Oct 20, 2015

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

@p5pRT
Copy link
Author

p5pRT commented Oct 20, 2015

From @bulk88

On Mon Oct 19 21​:53​:43 2015, tonyc wrote​:

I suspect PerlEx used it (ActiveState's IIS plugin), but the
interfaces all seem to make copies of the vtables rather than using
them in place and pointers to the original vtables don't seem to be
visible, so this patch is safe.

Tony

I've thought about getting rid of the copying of the vtables too. That code makes me think that it was designed so that perl523.dll can run on WinCE/Netware/Win32/who knows what else with no modifications to libperl, as if a shared library/binary can run on any x86 OS, just runtime swapping of the "OS layer". That code is so flexible the same libperl can work on linux and Win32 without a recompile assuming both OSes shared ELF or PE or AOUT.

--
bulk88 ~ bulk88 at hotmail.com

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

No branches or pull requests

1 participant