On Fri May 01 13:16:13 2009, coke wrote:
>
> What I meant was, I'll apply this in a few days (sometime this weekend)
> UNLESS I hear back from other darwin developers with complaints.
I tried the suggested deletion. It caused no problems for me on
Darwin/PPC. So +1 on the change.
kid51
Applied in r30907, thanks.
# New Ticket Created by "Paco Linux"
# Please include the string: [perl #58680]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=58680 >
Hi: a new PLATFORM Linux S/390, Parrot compiles without problems, make te
trunk/compilers/pge/PGE/Exp.pir
trunk/compilers/pge/PGE/OPTable.pir
trunk/compilers/pge/PGE/P5Regex.pir
trunk/compilers/pge/PGE/Perl6Regex.pir
trunk/config/gen/crypto/digest_pmc.in
trunk/config/gen/makefiles/root.in
trunk/config/gen/platform/ansi/exec.c
trunk/config/gen
# New Ticket Created by chromatic
# Please include the string: [perl #55806]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55806 >
How about we generate a makefile that is full of all the macros we need RM_F,
PERL, CP, et
On Tue, Apr 1, 2008 at 6:48 AM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> On Mon Mar 31 17:58:06 2008, [EMAIL PROTECTED] wrote:
> > config/gen/platform/darwin/dl.c uses deprecated functions whose better
> > performing replacements (dlopen and friends) were added in OS
On Mon Mar 31 17:58:06 2008, [EMAIL PROTECTED] wrote:
> config/gen/platform/darwin/dl.c uses deprecated functions whose better
> performing replacements (dlopen and friends) were added in OS X 10.3.
>
Is it possible that these deprecations were only made in OS X 10.5?
It appears that
On Mon Mar 31 17:58:06 2008, [EMAIL PROTECTED] wrote:
> config/gen/platform/darwin/dl.c uses deprecated functions whose better
> performing replacements (dlopen and friends) were added in OS X 10.3.
>
I don't get this result on OS X 10.4. Examining my 'make' logs over th
# New Ticket Created by "Seneca Cunningham"
# Please include the string: [perl #52346]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52346 >
config/gen/platform/darwin/dl.c uses deprecated functions
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #50768]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50768 >
I've updated some of the documenation and comments in
config/pl
Andy Armstrong wrote:
I uncommented the Parrot_cx calls and ran the tests twice - once with
CX_DEBUG = 1, once with CX_DEBUG = 0. It got through them all both times :)
Excellent!
Thanks,
Allison
On 12 Dec 2007, at 19:53, Allison Randal wrote:
So, I'm interested to see what your 10.5 box does.
I uncommented the Parrot_cx calls and ran the tests twice - once with
CX_DEBUG = 1, once with CX_DEBUG = 0. It got through them all both
times :)
--
Andy Armstrong, Hexten
Andy Armstrong wrote:
Again, let me know if you need more.
Could you give it another go with the latest revision? (You'll need to
uncomment the 'Parrot_cx...' lines in src/inter_create.c again, as I
commented them out in trunk while working on the hangs.)
I've eliminated the hangs on my du
Andy Armstrong wrote:
Again, let me know if you need more.
I pushed it far enough that I was able to repeat the deadlock hang on OS
10.4.11, that's good. The interesting thing was the order of operations.
The usual order is:
call to Parrot_cx_init_scheduler
initializing scheduler runloop
s
On 9 Dec 2007, at 21:02, Allison Randal wrote:
Andy Armstrong wrote:
And Instruments is telling me this:
http://hexten.net/junk/parrot1.png
Nice level of detail in this tool. Almost worth the cost of 10.5 all
on its own.
It seems rather lovely. Bear in mind that I didn't even launch it
u
Andy Armstrong wrote:
And Instruments is telling me this:
http://hexten.net/junk/parrot1.png
Nice level of detail in this tool. Almost worth the cost of 10.5 all on
its own.
It seems to hang much more readily with CX_DEBUG enabled - including
once during make rather than make test.
Good
On 07/12/2007, Allison Randal <[EMAIL PROTECTED]> wrote:
> Andy Dougherty wrote:
> >
> > Whether this is a defect in the vtables_4 test sourcefile for failing to
> > initialize the vtables, or whether pmc_new ought to be more defensive, I
> > can't say.
>
> Looks like a bug in the test, as there ar
On 8 Dec 2007, at 20:22, Allison Randal wrote:
Could you edit src/scheduler.c and change the value of CX_DEBUG to
1, recompile, and run the test suite? Most of the tests will fail
because of the additional output on stderr, but if you can catch a
hang, we'll have a little more detail on what
Andy Armstrong wrote:
On 8 Dec 2007, at 14:18, Andy Armstrong wrote:
Please let me know if there's anything you'd like me to investigate.
I'm afraid I don't know my way around parrot, er, at all - but I'm
willing to learn.
Ah, Mac OS 10.5 has dtrace - which I hadn't tried before but turns ou
On 8 Dec 2007, at 14:18, Andy Armstrong wrote:
Please let me know if there's anything you'd like me to investigate.
I'm afraid I don't know my way around parrot, er, at all - but I'm
willing to learn.
Ah, Mac OS 10.5 has dtrace - which I hadn't tried before but turns out
to be rather cool
On 8 Dec 2007, at 13:42, Allison Randal wrote:
Are you sure you've got the very latest version of all files on this
box ('make realclean', etc)?
Yup. I've just done make realclean && make && make test again and this
time it hung at
t/pmc/parrotlibrary1/1
(time
Andy Armstrong wrote:
But on Mac OS 10.5 I get random hangs. First at
t/op/01-parse_ops..287/335
for about ten minutes until I interrupted it and then
t/op/string_cs.1/50
for another ten or so minutes.
Are you sure you've got the
chromatic wrote:
On Ubuntu 7.10:
t/src/vtables..1/4
# Failed test (t/src/vtables.t at line 142)
# Exited with error code: [SIGNAL 139]
[...]
This didn't go away on a realclean. I even moved ending the runloop to before
the full DOD when destroying an interpreter, but to no effect.
On 7 Dec 2007, at 16:32, chromatic wrote:
On Friday 07 December 2007 05:23:39 Allison Randal wrote:
I'm about to turn on the concurrency scheduler runloop in Parrot
trunk.
Before I do, I'd like test results on as many platforms as possible
(especially Windows, since it doesn't use POSIX threa
On Friday 07 December 2007 05:23:39 Allison Randal wrote:
> I'm about to turn on the concurrency scheduler runloop in Parrot trunk.
> Before I do, I'd like test results on as many platforms as possible
> (especially Windows, since it doesn't use POSIX threads).
>
> To test it, edit src/inter_create
Andy Dougherty wrote:
Whether this is a defect in the vtables_4 test sourcefile for failing to
initialize the vtables, or whether pmc_new ought to be more defensive, I
can't say.
Looks like a bug in the test, as there are other things in Parrot_exit
that won't behave appropriately without an
On Fri, 7 Dec 2007, Allison Randal wrote:
> I'm about to turn on the concurrency scheduler runloop in Parrot trunk. Before
> I do, I'd like test results on as many platforms as possible (especially
> Windows, since it doesn't use POSIX threads).
>
> To test it, edit src/inter_create.c and uncomme
On Fri, Dec 07, 2007 at 08:45:03PM +0200, Allison Randal wrote:
> jerry gay wrote:
> >>
> >looks good to me. commit away!
> >nice work.
>
> I've got a clean report on our core platform targets, so committed in
> r23574. As usual, please report any issu
jerry gay wrote:
looks good to me. commit away!
nice work.
I've got a clean report on our core platform targets, so committed in
r23574. As usual, please report any issues.
Thanks!
Allison
On Dec 7, 2007 5:23 AM, Allison Randal <[EMAIL PROTECTED]> wrote:
> I'm about to turn on the concurrency scheduler runloop in Parrot trunk.
> Before I do, I'd like test results on as many platforms as possible
> (especially Windows, since it doesn't use POSIX threads).
>
> To test it, edit src/inte
I'm about to turn on the concurrency scheduler runloop in Parrot trunk.
Before I do, I'd like test results on as many platforms as possible
(especially Windows, since it doesn't use POSIX threads).
To test it, edit src/inter_create.c and uncomment the two lines that
start with 'Parrot_cx...".
On Thu Sep 13 22:39:32 2007, [EMAIL PROTECTED] wrote:
>
> On Sep 13, 2007, at 8:21 PM, Jerry Gay (via RT) wrote:
>
> > # New Ticket Created by Jerry Gay
> > # Please include the string: [perl #45437]
> > # in the subject line of all future correspondence about this issue.
> > # http://rt.perl.o
On Sep 13, 2007, at 8:21 PM, Jerry Gay (via RT) wrote:
# New Ticket Created by Jerry Gay
# Please include the string: [perl #45437]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45437 >
in r21240, ptc added a 'cover' tar
# New Ticket Created by Jerry Gay
# Please include the string: [perl #45437]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45437 >
in r21240, ptc added a 'cover' target to the makefile, along with
'cover-clean', which was
Can y'all please go update this page and talk about what platforms
you're using? I can never keep track of who's doing what.
http://www.perlfoundation.org/parrot/index.cgi?platforms
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
On 01/05/07, Nicholas Clark <[EMAIL PROTECTED]> wrote:
Given that that file starts:
/*
This is a version (aka dlmalloc) of malloc/free/realloc written by
Doug Lea and released to the public domain. Use, modify, and
redistribute this code without permission or acknowledgment in any
way y
On Tue, May 01, 2007 at 10:52:19PM +0100, Nicholas Clark wrote:
> > Date: Tue May 1 06:29:35 2007
> > New Revision: 18369
> >
> > Modified:
>
> >trunk/src/malloc.c
>
> > Modified: trunk/src/malloc.c
> > ==
>
> [316
> Date: Tue May 1 06:29:35 2007
> New Revision: 18369
>
> Modified:
>trunk/src/malloc.c
> Modified: trunk/src/malloc.c
> ==
[3168 lines of diff]
Given that that file starts:
/*
This is a version (aka dlmalloc)
On Sun, Jul 16, 2006 at 12:49:27PM +0100, Ron Blaschke wrote:
> On Win32 the implementation is simple because the IEEE recommended
> functions _finite and _isnan are supported. I'm thinking about adding a
> test for these functions and use them. But what should happen if they
> are not there?
n
coda to the generated file
+print PLATFORM_H <<"END_HERE";
+
+$coda
+END_HERE
+
close PLATFORM_H;
# implementation files are merged into platform.c
@@ -162,13 +184,20 @@
if (-e "config/gen/platform/$platform/begin.c") {
local $/ = undef;
open I
On Wed, Jul 26, 2006 at 01:21:11PM -0700, Bill Coffman wrote:
> That being said, you can optimize by looking at the bits. Wikipedia
> explains IEEE-754 http://en.wikipedia.org/wiki/IEEE_754
> First, you have to be aware if the machine is big or little-endian, second,
Beware. It's legal for the e
Bill Coffman wrote:
> There is no platform independent way to produce "NaN" or "Inf", so IMHO,
> you
> did it the only way it can be done.
>
> That being said, you can optimize by looking at the bits. Wikipedia
> explains IEEE-754 http://en.wikipedia.o
On 7/26/06, Ron Blaschke <[EMAIL PROTECTED]> wrote:
I'm looking into this issue and would like to ask for some advice.
I have added the following platform dependent functions.
int Parrot_math_isnan(double)
int Parrot_math_finite(double)
On Win32 the implementation is simple becau
I'm looking into this issue and would like to ask for some advice.
I have added the following platform dependent functions.
int Parrot_math_isnan(double)
int Parrot_math_finite(double)
On Win32 the implementation is simple because the IEEE recommended
functions _finite and _isnan are supp
I'm looking into this issue and would like to ask for some advice.
I have added the following platform dependent functions.
int Parrot_math_isnan(double)
int Parrot_math_finite(double)
On Win32 the implementation is simple because the IEEE recommended
functions _finite and _isnan are supp
On Mon, Jun 26, 2006 at 12:08:52PM -0500, Vishal Soni wrote:
> Hi Chip,
> Let me know what your thoughts are. I would not mind writing up a draft PDD
> or doing some proof of concept work.
Chip's currently at YAPC::NA, and he's not yet presented his talk, so I'm
guessing it might be a little whil
Hi Chip,
I have been looking at the Parrot code for last couple of weeks. While going
through the code there were a few things that striked me. There are quite a
few places where #ifdef constructs were used to define platform specific
code (#ifdef WIN32).
I was thinking would it make sense to
# New Ticket Created by Ron Blaschke
# Please include the string: [perl #38887]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38887 >
.sub main
# produce INFINITY (is there a constant for that?)
set N0, 0.0
ln
# New Ticket Created by Will Coleda
# Please include the string: [perl #38467]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38467 >
Right now the Parrot::Test module is explicitly doing a check for a /
dev/null and chan
At 04:58 14/10/2005 -0700, you wrote:
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #37434]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37434 >
Simon Vogl wrote:
[ ... ]
Here are some rele
At 04:58 14/10/2005 -0700, you wrote:
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #37434]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37434 >
Simon Vogl wrote:
[ ... ]
Here are some rele
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #37434]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37434 >
Simon Vogl wrote:
[ ... ]
Here are some relevant snippets auf Parrot on ARM (see a
Jeff Clites <[EMAIL PROTECTED]> wrote:
> This patch makes scan_paths() copy the passed-in string,
Thanks, applied, as well as #31927
leo
it and ultimately this (seemingly) would chew up a couple
of environment variables; this also gets rid of a compiler warning
about casting away the constness of libpath, which we shouldn't have
been doing (since in fact it was being modified).
JEff
Index: config/gen/platform/dar
At 8:37 AM -0700 9/1/04, [EMAIL PROTECTED] (via RT) wrote:
On Solaris 8, asctime_r takes 3 parameters instead of 2. The
prototype looks like this:
char *asctime_r(const struct tm *tm, char *buf, int buflen);
This patch adds a time.c file to the solaris platform directory. The
only change in this
oks like this:
char *asctime_r(const struct tm *tm, char *buf, int buflen);
This patch adds a time.c file to the solaris platform directory. The
only change in this time.c file and the stock generic/time.c is that
the call to asctime_r passes 26 as the buflen.
The Solaris man page for asctime_r s
Sat Aug 14 14:34:05 2004
+++ config/gen/config_h/config_h.in Sat Aug 14 14:34:27 2004
@@ -71,6 +71,7 @@
#define INT_SIZE ${intsize}
#define LONG_SIZE ${longsize}
#define HUGEINTVAL_SIZE ${hugeintvalsize}
+#define DOUBLE_SIZE ${doublesize}
/* We don't have a portable config for 64-
improvement without some porting help (please contact me if
you want to help out). If the new building process can't be done on a
platform, it uses the original slow building process (this only happens
when we don't have access to the compiler or platform for testing).
Item 2 c
On Apr 15, 2004, at 11:12 AM, George R wrote:
I couldn't help but notice that you were talking about ICU on this
mailing list. Let me interject with some suggestions.
Thanks much for the message.
I should mention that ICU 2.6 can build a static data library. I
recommend that ICU be built with
Hello Perl6 people,
I couldn't help but notice that you were talking about ICU on this
mailing list. Let me interject with some suggestions.
I should mention that ICU 2.6 can build a static data library. I
recommend that ICU be built without the --with-data-packaging=archive
configure option
At 7:13 AM -0800 3/30/04, mrnobo1024 (via RT) wrote:
The second arg of GetExitCodeProcess should be a pointer to DWORD, not int,
this was causing a warning on mingw:
src/platform.c: In function `Parrot_Run_OS_Command':
src/platform.c:446: warning: passing arg 2 of `GetExitCodeProcess' from
incompat
on time.
http://taxes.yahoo.com/filing.html--- config/gen/platform/win32/exec.c~ Wed Mar 3 16:06:08 2004
+++ config/gen/platform/win32/exec.cSat Mar 27 10:29:10 2004
@@ -4,7 +4,7 @@
*/
INTVAL
Parrot_Run_OS_Command(Parrot_Interp interpreter, STRING *command) {
-int status = 0;
+DWO
inter type
__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html--- config/gen/platform/win32/exec.c~ Wed Mar 3 16:06:08 2004
+++ config/gen/platform/win32/exec.cSat Mar 27 10:29:10 2004
@@ -4,7 +4,7 @@
*/
INTVAL
Parrot_Run_
Leopold Toetsch wrote:
Courtesy of Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Er...that wasn't me--I was just passing it along, as I said in the
message. (If it was me, I'd likely have committed it myself. ;^) )
Credit goes to Matt Fowles <[EMAIL PROTECTED]>.
(Leo, I tried to send this to you
On Sat, 2004-02-28 at 03:43, Leopold Toetsch wrote:
> CGoto core: make testg testC
Both of these worked on Linux PPC with gcc-3.2.3
I did see an intermittent hang, this time on the second test of
t/src/intlist.t. killall -HUP intlist_2 made the test continue, though
it failed.
> JIT:m
On Sat, 2004-02-28 at 06:43, Leopold Toetsch wrote:
> Kenneth A Graves <[EMAIL PROTECTED]> wrote:
> > On Fri, 2004-02-27 at 16:08, Kenneth A Graves wrote:
> >>
> >> How do I verify which runloops/features are working?
>
> CGoto core: make testg testC
Both give:
All tests successful, 1 test and 61
Kenneth A Graves <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-02-27 at 16:08, Kenneth A Graves wrote:
>>
>> How do I verify which runloops/features are working?
CGoto core: make testg testC
JIT:make testj
> I added " or $^O eq 'freebsd'" to t/pmc/{threads,timer}.t and those
> tests run succe
On Fri, 2004-02-27 at 16:08, Kenneth A Graves wrote:
> I think this gives a PLATFORMS line of:
> freebsd5.2-i386 YYY ? ? Y Y
>
> How do I verify which runloops/features are working?
I added " or $^O eq 'freebsd'" to t/pmc/{threads,timer}.t and those
tests run
.0.13 configuration:
configdate='Fri Feb 27 15:49:20 2004'
Platform:
osname=freebsd, archname=i386-freebsd
jitcapable=1, jitarchname=i386-freebsd,
jitosname=FREEBSD, jitcpuarch=i386
execcapable=1
perl=perl
Compiler:
cc='cc', ccflags='-DAPPLLIB_EXP=&quo
--- via RT <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> # New Ticket Created by [EMAIL PROTECTED]
> # Please include the string: [perl #27042]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org:80/rt3/Ticket/Display.html?id=27042 >
>
> ATTACHMENT
Nigelsandever @ Btconnect . Com <[EMAIL PROTECTED]> wrote:
> This patch implements Parrot_Run_OS_Command() for Win32.
Thanks, applied.
> Whilst I'm posting this, I will mention the following build error
> platform.c
Should be fixed now.
leo
U1077: 'c:\Perl\bin\perl.exe' : return code '0x2'
I bypassed this by commenting out the following code section in src/platform.c
(207) as a temporary measure.
/*
** config/gen/platform/generic/signal.c:
*/
/*
* Signal handling stuff
*/
#ifdef PARROT_
- Original Message -
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
To: "Jonathan Worthington" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, February 21, 2004 11:51 AM
Subject: Re: [PATCH] Re: [perl #25239] Platform-specific files not gr
Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> I've attached a patch which causes stuff in begin.c to be put before the
> #include "parrot/parrot.h" line, which fixes up this problem. I don't know
> if it's the right thing to do, but it's the best one I could think of.
Applied.
> Please crea
> -Original Message-
> From: Jonathan Worthington [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 20, 2004 4:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PATCH] Re: [perl #25239] Platform-specific files not
> granular enough
>
>
[snip]
>
> Creating an
- Original Message -
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
To: "Jonathan Worthington" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, February 19, 2004 7:06 PM
Subject: Re: [PATCH] Re: [perl #25239] Platform-specific files not gr
Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> src\exceptions.c
> exceptions.c
> c:\documents and settings\jonathan\desktop\pow\parrot\src\exceptions.c(125)
> : error C2065: 'SIGQUIT' : undeclared identifier
Seems that dumpcore is used from generic/signal.h
You could try to create an empty wi
- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, February 19, 2004 3:10 PM
Subject: [PATCH] Re: [perl #25239] Platform-specific files not granular
enough
> At 8:01 PM + 2/18
At 8:01 PM + 2/18/04, Adam Thomason via RT wrote:
Attached patch is tested on Linux, AIX, and OpenBSD. It does
twiddle the order of includes and declarations, so there might still
be problems. Testing very much requested, most especially on Darwin
and Win32.
I've applied this locally and i
Adam Thomason <[EMAIL PROTECTED]> wrote:
[ big patch ]
Thanks, applied.
leo
> -Original Message-
> From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 19, 2004 1:00 AM
> To: Adam Thomason
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PATCH] Re: [perl #25239] Platform-specific
> files not granular enough
>
> BTW wha
Adam Thomason wrote:
Hopefully in time to make the feature freeze, here's an effort at solving this problem.
Looks really good. I've applied it here (with little tweaks in
Configure/Step.pm) and it works fine.
Testing very much requested, most especially on Darwin and Win32.
Yeah. Anyway, I'll
Hopefully in time to make the feature freeze, here's an effort at solving this
problem. I went through the platform .c and .h files and broke out the redundant bits
into the following "modules", which were already delimited by comments in generic.*:
dl: dynamic
While we're about it, there's a need for platform specific .s files as well, since
some compilers like xlc don't support inlined asm. There's a ia64.s already in cvs,
but I don't see by what magic it actually gets built (if it even is). Configure
should likely have
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #25239]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=25239 >
We've got per-platform .c and .h files that get loaded in by
configure.pl,
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> I'll check in a test if malloced memory is executable RSN.
The check is in. On fedora, the Configure line of JIT should have
(has_exec_protect yes)
If that's ok, some define in a header should be set.
We currently seem to be missing a general solu
Peter Gibbs <[EMAIL PROTECTED]> wrote:
> Log:
> Prevent attempts to reallocate mmap'd executable memory until somebody
> works out how to do it.
For linux/fedora, I'd go with this scheme:
- mem_alloc_executable uses valloc() that is memalign(getpagesize(),
size) with size rounded up t
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 17, 2003 at 08:40:44PM -0400, Benjamin Goldberg wrote:
>> When there are no events queued, for any thread, then we change "branch
>> e_handler_foo" back into "branch label_foo", for speed.
> Do we need to do this last bit explicitly? Or can
Nicholas Clark wrote:
On Thu, Jul 17, 2003 at 08:40:44PM -0400, Benjamin Goldberg wrote:
Actually, I'm thinking of something like the following... suppose the
original code is like:
label_foo:
loop body
branch_address:
branch label_foo
Add in the following:
e_handler_foo:
.local Perl
On Thu, Jul 17, 2003 at 08:40:44PM -0400, Benjamin Goldberg wrote:
> Actually, I'm thinking of something like the following... suppose the
> original code is like:
>
>label_foo:
>loop body
>branch_address:
>branch label_foo
>
> Add in the following:
>
>e_handler_foo:
>.l
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Not "the next instruction" ... the next *branch* instruction. And only
> replace those branch instructions which could be loops.
Works. Many thanks for the input.
I have now running this:
1) Initialization:
- normal core: build op_func_table wi
Sean O'Rourke wrote:
>
> On Thu, 17 Jul 2003, Leopold Toetsch wrote:
> > PC = ((op_func_t*) (*PC)) (PC, INTERP); // prederef functions
> >
> > To be able to switch function tables, this then should become:
> >
> > PC = ((op_func_t*) (func_table + *PC)) (PC, INTERP);
> >
> > Thus prederefernc
Sean O'Rourke wrote:
On Thu, 17 Jul 2003, Leopold Toetsch wrote:
Replacing the next instruction with a branch to the signal handler
(like adding a breakpoint) out of the question?
I don't know, how to get the address of the next instruction i.e. the
"PC" above.
Thinking more of this: There is no
this way would either mean:
> - fill the bytecode segment with the handler opcode function or
Yuck.
> - locate the PC on the stack or in registers (like %esi in CGP)
> The former seems rather expensive (at least if we heavily use events),
> the latter seems to be possible only per plat
least if we heavily use events),
the latter seems to be possible only per platform/compiler(-revision).
...Of course, if we're
sharing bytecode this is expensive, since you'd have to do something
like this:
The prederefed code can't be shared betwean threads: Registers are
On Thu, 17 Jul 2003, Leopold Toetsch wrote:
> PC = ((op_func_t*) (*PC)) (PC, INTERP); // prederef functions
>
> To be able to switch function tables, this then should become:
>
> PC = ((op_func_t*) (func_table + *PC)) (PC, INTERP);
>
> Thus predereferncing the function pointer would place an of
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> ... Switching the whole op_func_table() or
> ops_addr[] (for CG cores) is simpler,
If have it running now for the slow and the computed goto core.
The signal handler (interrupt code) switches the op_func_table (ops_addr)
and returns.
Then the next execu
On Tue, Jul 15, 2003 at 10:15:57AM +0200, Leopold Toetsch wrote:
How is the described scheme supposed to work with JIT generated code ?
--
Jason
Gregor N. Purdy <[EMAIL PROTECTED]> wrote:
> #define DO_OP(PC,INTERP) \
> (PC = ((INTERP->op_func_table)[*PC])(PC,INTERP))
> The easiest way to intercept this flow with minimal cost is to
> have the mechanism that wants to take over replace the interpreter's
> op_func_table with a block of po
Gregor N. Purdy <[EMAIL PROTECTED]> wrote:
> Benjamin --
> #define DO_OP(PC,INTERP) \
> (PC = ((INTERP->op_func_table)[*PC])(PC,INTERP))
> The easiest way to intercept this flow with minimal cost is to
> have the mechanism that wants to take over replace the interpreter's
> op_func_table with
1 - 100 of 144 matches
Mail list logo
