Re: Destruction bug in make test.
Dan Sugalski [EMAIL PROTECTED] wrote: No. If any object has a destructor it should be called as the last interpreter is shut down. We're not guaranteeing dead-on immediate destruction, or if the timely flag isn't set timely destruction, but we *are* guaranteeing eventual destruction. Oha. That explains the reasoning. That adds a third category to destruction IMHO: 1) timely destruction on scope exits 2) eventual destruction on exit of interpreters 3) memory destruction for leak tests and such or for intermediate interpreters. For 1) we have opcode support Cneeds_destroy. 2) seems to be the case where IO objects jump in - and HLL destructors. We don't need to free memory, but we do need to call destructors. So we'd better separate 2) and 3) This would simplify destruction ordering and speedup interpreter shutdown. Dan leo
Re: [perl #24177] [PATCH] Make Parrot dlcompat aware on OS X
Michael Scott [EMAIL PROTECTED] wrote: config/gen/platform/darwin.c Add conditional code for PARROT_HAS_HEADER_DLFCN. Could you please rediff the patch w/o the whitespace changes. An indent of 4 is ok, you seem to have 8 in place. Thanks. leo
Re: [perl #24169] pthread required to build parrot on freebsd
Peter Sinnott [EMAIL PROTECTED] wrote: A proposed freebsd hint file is attached( a copy of the current aix hint file ) Thanks applied. leo
Re: Destruction bug in make test.
Leopold Toetsch [EMAIL PROTECTED] writes: Juergen Boemmels [EMAIL PROTECTED] wrote: It turned out, that it was even simpler. The explicit sweeping is already in the code, but is only triggered if there are objects which need _early_ destruction, not if objects just need destruction. Removing this test made it work. Why can't you call PIO_finish(DO_FLUSH) before the sweep? Because the object in question is not in PIO_data. Its just a plain PMC with a destroy-function. And this destroy-function was not run until now. Some other bug was hiding that fact. I don't understand these workarounds. Also you mark the IOdata live, only that they are destroyed 3 lines later then. Thats something completely different and I addmit it is a hack. When I introduced this, I had problems with closing the three _standard_ handles to early. Maybe I don't need this hack any more because the handles are now only flushed (not tested). But I left it in because its a matter of correctness. One destroy-function which prints and the problem is there again. The correct solution to this problem is destruction ordering: The standard handles should be destroyed after the interpreter (which isn't a PMC yet). If there are no objects that need timely destruction, the sweep is wasted time. Fix is commited. Not IMHO. PIO_finish still does not release the standard handles and valgrind complains about invalid reads in PIO_flush_down. I think this is one (or two) other problems. When I think about it, I just flush the buffers, but do not free them. Will look at the code now. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Destruction bug in make test.
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: No. If any object has a destructor it should be called as the last interpreter is shut down. We're not guaranteeing dead-on immediate destruction, or if the timely flag isn't set timely destruction, but we *are* guaranteeing eventual destruction. Oha. That explains the reasoning. That adds a third category to destruction IMHO: 1) timely destruction on scope exits 2) eventual destruction on exit of interpreters or any time between the death of the object and the and of universe^H^H^Hinterpreter. But no guarantee when. 3) memory destruction for leak tests and such or for intermediate interpreters. For 1) we have opcode support Cneeds_destroy. 2) seems to be the case where IO objects jump in - and HLL destructors. We don't need to free memory, but we do need to call destructors. So we'd better separate 2) and 3) This would simplify destruction ordering and speedup interpreter shutdown. The code is already there. The final sweep runs the destructors. The problem was that 1) and 2) were to strongly coupled. All destructors were only run if one object exists which needed timely destruction. Maybe we should generate another PMC which uses destruction functions, just for testing these things. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [perl #24169] pthread required to build parrot on freebsd
Nicholas Clark [EMAIL PROTECTED] wrote: I'm having trouble testing this because I can't get CVS parrot to build on my (friend's) freebsd box. I think that this ought to restore 5.005_03 compatibility: parrot builds and tests fine here with 5.005_03 $ perl5.00503 -V Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=linux, osvers=2.2.16, archname=i586-linux uname='linux maclaurin.suse.de 2.2.16 #1 mon mar 13 10:51:48 gmt 2000 i686 unknown ' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O2 -pipe', gccversion=2.95.2 19991024 (release) cppflags='-Dbool=char -DHAS_BOOL -I/usr/local/include' ccflags ='-Dbool=char -DHAS_BOOL -I/usr/local/include' stdchar='char', d_stdstdio=undef, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt libc=, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Built under linux Compiled at Jul 30 2000 18:58:03 @INC: /usr/lib/perl5/5.00503/i586-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i586-linux /usr/lib/perl5/site_perl/5.005 . $ gcc --version 2.95.2 $ uname -a Linux thu8 2.2.16 #5 Thu Oct 12 20:07:01 CEST 2000 i686 unknown
Re: Destruction bug in make test.
On Fri, 10 Oct 2003, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: No. If any object has a destructor it should be called as the last interpreter is shut down. We're not guaranteeing dead-on immediate destruction, or if the timely flag isn't set timely destruction, but we *are* guaranteeing eventual destruction. Oha. That explains the reasoning. That adds a third category to destruction IMHO: 1) timely destruction on scope exits 2) eventual destruction on exit of interpreters 3) memory destruction for leak tests and such or for intermediate interpreters. For 1) we have opcode support Cneeds_destroy. 2) seems to be the case where IO objects jump in - and HLL destructors. We don't need to free memory, but we do need to call destructors. So we'd better separate 2) and 3) This would simplify destruction ordering and speedup interpreter shutdown. Sure, that works. We do need to be able to free up all an interpreter's allocated memory, so we don't leak when we're embedded in some other application, but running the destructors is definitely more important. Dan
Re: [perl #24177] [PATCH] Make Parrot dlcompat aware on OS X
On Fri, 10 Oct 2003, Leopold Toetsch wrote: Michael Scott [EMAIL PROTECTED] wrote: config/gen/platform/darwin.c Add conditional code for PARROT_HAS_HEADER_DLFCN. Could you please rediff the patch w/o the whitespace changes. An indent of 4 is ok, you seem to have 8 in place. Actually, I'd rather not do this. We linked against Fink under OS X originally, to get library loading, but ended up not doing it any more because too many people didn't have it, and it seemed to mess up some people's systems. I'll try and get the alternate dynaloader for OS X built this weekend. Dan
Re: An evil task for the interested
On Thu, 9 Oct 2003, Thomas Fjellstrom wrote: On October 9, 2003 09:57 am, Dan Sugalski wrote: On Thu, 9 Oct 2003, Dave Mitchell wrote: On Thu, Oct 09, 2003 at 11:43:41AM -0400, Dan Sugalski wrote: We've got ordered destruction on the big list 'o things to do, and it looks like we need to get that done sooner rather than later. So, this is a good chance for someone to burn those surplus SAN points and become one with the great gibbering chaos at the center of the universe (no, wait, that's not it) by digging into the DOD system. Not a huge task, we just need to order PMCs before destroying them, to make sure we don't call the destructor for a PMC before we destroy the things that depend on it. A quick run through the PMC pools to build up a dependency chain if there's more than one PMC that needs destruction should do it. I always thought that was a rather hard issue, due to circular dependencies. It's certainly the case that Perl5 is very poor at global destruction of objects. In the circular case you just pick a place and go from there -- there's no good way to handle those. There are a lot of cases where there are non-circular dependencies, though, so it seems worthwhile to take those in order. Probably ought to be optional for all the sweeps except, perhaps, the final one, though I expect perl, python, and ruby code will all enable ordered destruction. I've been interested in how to clean up circular dependencies... Just how easy is it to find all cases? Is it possible? Like say a really really deep case... Should you just not care at that point, and say the programmer deserves what [s]he gets? It's pretty easy to find the cases--if you pick an object with an active destroy method, start tracing the tree, and hit that object during the trace then you've got a circular structure. There's no reliable way of properly cleaning these up, since any scheme you can think of (and people have thought up a lot of 'em) can run leave you with a situation you can't reasonably resolve. The only good thing to do is clean up all the non-circular structures and see if there's anything left (since sometimes destructors on other objects can end up resolving the issue) and, if there is, picking an object at random to start the destruction with. And for parrot, it *should* be random, if we're not otherwise going to set a scheme in place. (Complete with calls to rand() and everything) Dan
Re: [COMMIT] new IO op 'pioctl'
On Thu, 9 Oct 2003, Melvin Smith wrote: Added pioctl op and PIO_pioctl API call. General purpose op for IO manipulation in tradition of UNIX ioctl call. This will be the interface for doing all sorts of IO layer stuff such as buffering, blocking, async, etc. At least until someone has a better way to do it. I think it's time to start thinking about it. (And I think we need a new name, but that's because I've always hated 'ioctl' :) Dan
Re: Linebuffering and readline
On Thu, 9 Oct 2003, Melvin Smith wrote: I fixed a bug in the readline routine that now allows it to act like it should. With the ability to toggle linebuffering on IO handles now with pioctl, do we need the explicit readline op anymore? If it's identical to a read now, then no. We might want to consider having an alias in the assembler, but that's it, the op itself can go. Dan
Re: [COMMIT] new IO op 'pioctl'
At 08:31 AM 10/10/2003 -0400, Dan Sugalski wrote: On Thu, 9 Oct 2003, Melvin Smith wrote: Added pioctl op and PIO_pioctl API call. General purpose op for IO manipulation in tradition of UNIX ioctl call. This will be the interface for doing all sorts of IO layer stuff such as buffering, blocking, async, etc. At least until someone has a better way to do it. I think it's time to start thinking about it. (And I think we need a new name, but that's because I've always hated 'ioctl' :) :) I also considered iocmd, ioattr and ioset. IPop your favorite into the suggestion box... -Melvin
Re: Library loading and initialization sequence
Dan Sugalski [EMAIL PROTECTED] wrote: Right now there's a load_pmc op, which goes along with the load_opcode_lib and loadlib ops. I'd like to unify that I'll start the opcode load thingy, based on my experimental code I has posted here mid-March. The basics are: - assembler and runtime must see the Cloadlib oplib in the same sequence, because - the opcode numbers are assigned dynamically: When you load an oplib containing 100 ops, they get op numbers e.g. 1206 ... 1305. Next oplib starts at 1306 ... - on load all runcores are notified to use the new oplib function or address table There are for sure issues e.g. when you run the CGP core and the loaded lib has functions only, but a default handler in the jump table can call these functions then. The switched core also need this default handling. ... Parrot_lib_load_%s ... ... returns a PMC representing the library Any hints, what kind of PMC that shall be? An new Parrot_Lib PMC with the dll handle attached + some flags about the library and its contents? Dan leo
[CVS ci] Remove of PutS and GetS from PIOLayerAPI
Hi, I just removed the PutS and GetS functions PIOLayerAPI. This API-functions used plain C-Strings and had no advantage over the Read and Write API-calls. They just introduced a second code-path. The only function actually using this API was PIO_puts, which was easily changed to use the Write API. I also temporarily disabled t/pmc/io_21 (seek/tell), because of some bugs in the seek/tell implementation in io_buf, which I want to address next. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [perl #24177] [PATCH] Make Parrot dlcompat aware on OS X
On Friday, Oct 10, 2003, at 14:22 Europe/Berlin, Dan Sugalski wrote: On Fri, 10 Oct 2003, Leopold Toetsch wrote: Michael Scott [EMAIL PROTECTED] wrote: config/gen/platform/darwin.c Add conditional code for PARROT_HAS_HEADER_DLFCN. Could you please rediff the patch w/o the whitespace changes. An indent of 4 is ok, you seem to have 8 in place. Actually, I'd rather not do this. We linked against Fink under OS X originally, to get library loading, but ended up not doing it any more because too many people didn't have it, and it seemed to mess up some people's systems. I thought you might say that, which was why I made it a well-if-it's-there kind of thing. I really just wanted to see the ncurses life example working, but that died with the following dlcompat error anyway: unable to open this file with RTLD_LOCAL because it doesn't implement RTLD_LOCAL. I'll try and get the alternate dynaloader for OS X built this weekend. If I can be of any assistance with this let me know. Dan
Re: Library loading and initialization sequence
On Fri, 10 Oct 2003, Leopold Toetsch wrote: - the opcode numbers are assigned dynamically: When you load an oplib containing 100 ops, they get op numbers e.g. 1206 ... 1305. Next oplib starts at 1306 ... - on load all runcores are notified to use the new oplib function or address table I've been thinking about this, and I've decided that loading oplibs and installing those oplib functions in the current table should be separate things. The load can do whatever it wants to initialize, but when the functions are installed in the opcode dispatch table that's when the interpreter says where the functions should go. There are for sure issues e.g. when you run the CGP core and the loaded lib has functions only, but a default handler in the jump table can call these functions then. The switched core also need this default handling. ... Parrot_lib_load_%s ... ... returns a PMC representing the library Any hints, what kind of PMC that shall be? An new Parrot_Lib PMC with the dll handle attached + some flags about the library and its contents? At the moment, no. I knew we'd want a thing to hang stuff off of, hence the PMC mandate. I'm not sure what that stuff should be yet, nor what we might want to make it do. We can throw it into a ParrotLibrary PMC and think about it as we go. Dan
[RfC] return value of PIO_seek
Hi,
I'm currently working on some bugs in the PIO_seek code, and i find
the current return-code of Seek impractical: it just returns 0 on
success and -1 on error. I found myself writing code like
PIO_seek_down(...);
pos = PIO_tell_down(...);
but in the layer implementations typically is this code:
return pos == -1 ? -1 : 0;
So i think it would be better to let PIO_seek return the current
offset. So I purpose a change of the prototype of PIO_seek to
PIOOFF_T PIO_seek(theINTERP, PMC *io, PIOFF_T offset, INTVAL whence);
The error checking can still be done by
if (PIO_seek(...) 0) {
/* an error occured */
}
Comments?
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [perl #24169] pthread required to build parrot on freebsd
On Fri, Oct 10, 2003 at 12:35:23PM +0200, Leopold Toetsch wrote:
Nicholas Clark [EMAIL PROTECTED] wrote:
I'm having trouble testing this because I can't get CVS parrot to build on
my (friend's) freebsd box. I think that this ought to restore 5.005_03
compatibility:
parrot builds and tests fine here with 5.005_03
$ perl5.00503 -V
5.005_03's man page only has:
open FILEHANDLE,EXPR
open FILEHANDLE
(ie no 3 argument form)
I infer that you are not hitting the TOUCH in imcc's Makefile:
echo languages/imcc/imcc.y -d -o languages/imcc/imcparser.c
languages/imcc/imcc.y -d -o languages/imcc/imcparser.c
/export/home/nwc10/bin/perl5.00503 -e 'open(A,q{},$_) or die foreach @ARGV'
languages/imcc/imcc.y.flag languages/imcc/imcparser.c languages/imcc/imcparser.h
Too many arguments for open at -e line 1, near $_)
Execution of -e aborted due to compilation errors.
*** Error code 255
Nicholas Clark
Missing file checkin
The tinders are complaining about missing dynoplibs/Makefile. While I'm not sure we should ultimately have a static makefile anywhere, I'm pretty sure that if we *do* have one mentioned in the Manifest that it ought to be in the repository... :) Dan
Re: [RfC] return value of PIO_seek
At 07:01 PM 10/10/2003 +0200, Juergen Boemmels wrote: Hi, I'm currently working on some bugs in the PIO_seek code, and i find the current return-code of Seek impractical: it just returns 0 on success and -1 on error. I found myself writing code like PIO_seek_down(...); pos = PIO_tell_down(...); but in the layer implementations typically is this code: return pos == -1 ? -1 : 0; So i think it would be better to let PIO_seek return the current offset. So I purpose a change of the prototype of PIO_seek to That sounds proper as that is the traditional semantic for seek/lseek on most systems. I'm not sure why I wrote it otherwise, probably just in haste. -Melvin
Re: cvs commit: parrot/io io.c io_buf.c
Which ones? The PIOCTL ones are, for a lack of current
interface, a way for interfacing to the lower level IO
system through a catchall opcode. It can be anything from
setting terminal modes, buffering, separator characters, the
list goes on.
Although we probably want to make separate ops for
common things like setting blocking mode, async/sync, etc. there are
usually a lot of little operations or queries that you might want
to do on an IO system that might not warrant a separate op for each.
I personally don't like to add an opcode for every special case
because most of them are very rarely used, but as usual its
up for discussion.
-Melvin
At 04:46 PM 10/10/2003 +0100, Nicholas Clark wrote:
On Fri, Oct 10, 2003 at 02:43:10AM -, Melvin Smith wrote:
+else if(arg == PIOCTL_BLKBUF) {
+ PIO_setbuf(interpreter, pmc, PIO_UNBOUND);
+ return 0;
+}
+else return -3;
case PIOCTL_CMDGETBUFSIZE:
if(b) return b-size;
else return -6;
What are all these magic numbers about?
Nicholas Clark
Re: cvs commit: parrot/io io.c io_buf.c
On Fri, Oct 10, 2003 at 05:55:11PM -0400, Melvin Smith wrote:
Which ones? The PIOCTL ones are, for a lack of current
interface, a way for interfacing to the lower level IO
system through a catchall opcode. It can be anything from
setting terminal modes, buffering, separator characters, the
list goes on.
Sorry. Wasn't clear. The PIOCTL macros are (to me) the correct way of doing
something.
-6 and -3 are magic numbers. They have no context as to what they might be.
At 04:46 PM 10/10/2003 +0100, Nicholas Clark wrote:
On Fri, Oct 10, 2003 at 02:43:10AM -, Melvin Smith wrote:
+else if(arg == PIOCTL_BLKBUF) {
+ PIO_setbuf(interpreter, pmc, PIO_UNBOUND);
+ return 0;
+}
+else return -3;
case PIOCTL_CMDGETBUFSIZE:
if(b) return b-size;
else return -6;
What are all these magic numbers about?
Nicholas Clark
Nicholas Clark
FreeBSD (4.8) can't build imcc
the top level Makefile has this rule to build the object files in
languages/imcc:
$(IMCC_DIR)/%.o : $(IMCC_DIR)/%.c
$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) -I$(IMCC_DIR) $(CFLAGS) -o $@ -c
$
the build fails at imcparser.o for me (the first object file)
Running make with some debug flags gives:
SuffFindDeps (languages/imcc/imcparser.o)
trying languages/imcc/imcparser.c...got it
applying .c - .o to languages/imcc/imcparser.o
SuffFindDeps (languages/imcc/imc.h)
SuffFindDeps (languages/imcc/stacks.h)
SuffFindDeps (languages/imcc/cfg.h)
SuffFindDeps (languages/imcc/instructions.h)
SuffFindDeps (languages/imcc/debug.h)
SuffFindDeps (languages/imcc/sets.h)
SuffFindDeps (languages/imcc/symreg.h)
SuffFindDeps (languages/imcc/pbc.h)
SuffFindDeps (languages/imcc/optimizer.h)
SuffFindDeps (languages/imcc/parser.h)
SuffFindDeps (languages/imcc/imcparser.h)
SuffFindDeps (languages/imcc/imcc.y)
echo languages/imcc/imcc.y -d -o languages/imcc/imcparser.c
languages/imcc/imcc.y -d -o languages/imcc/imcparser.c
/export/home/nwc10/bin/perl5.00503 -e 'open(A,qq{$_}) or die foreach @ARGV'
languages/imcc/imcc.y.flag languages/imcc/imcparser.c languages/imcc/imcparser.h
SuffFindDeps (languages/imcc/imcparser.c)
trying languages/imcc/imcparser.y...not there
trying languages/imcc/imcparser.l...not there
/export/home/nwc10/bin/perl5.00503 tools/dev/cc_flags.pl ./CFLAGS ccache gcc
-I/usr/local/include -g -Dan_Sugalski -Larry -Wall -Wstrict-prototypes
-Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align
-Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -I./include
-DHAS_JIT -DI386 -DHAVE_COMPUTED_GOTO -o languages/imcc/imcparser.o -c
languages/imcc/imcparser.c
languages/imcc/imcparser.c
imcc.y:20: imc.h: No such file or directory
imcc.y:21: pbc.h: No such file or directory
imcc.y:22: parser.h: No such file or directory
*** Error code 1
Having a grovel around the FreeBSD make and GNU make documentation suggests
that $(IMCC_DIR)/%.o : $(IMCC_DIR)/%.c is a GNU make pattern rule, and
means nothing to FreeBSD. However, I'm not convinced that that rule is
even necessary, as IIRC the C compiler should be looking for include files
in the same directory as the source.
(yes. should. It is probably not portable. IIRC I read somewhere that
trying to compile source code outside the current directory is not portable.
Or at least trying to use -c to direct the object file to somewhere other
than the same directory as the source would fail)
Aha. *This* patch fixes it:
--- languages/imcc/imcparser.c~ Tue Sep 30 22:06:02 2003
+++ languages/imcc/imcparser.c Fri Oct 10 23:15:05 2003
@@ -209,7 +209,7 @@
/* Copy the first part of user declarations. */
-#line 1 imcc.y
+#line 1 languages/imcc/imcc.y
/*
* imcc.y
I don't think that we can put this in. So, to cut a long ramble short
1: FreeBSD make doesn't understand those % pattern rules
2: gcc 2.95 resets its idea of the source file directory on a #line
directive, and as a consequence can't find other files to include
in that directory
Not sure how to solve this short of changing directory.
Nicholas Clark
Re: Library loading and initialization sequence
On Fri, Oct 10, 2003 at 05:44:05PM +0200, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: On Fri, 10 Oct 2003, Leopold Toetsch wrote: - the opcode numbers are assigned dynamically: When you load an oplib containing 100 ops, they get op numbers e.g. 1206 ... 1305. Next oplib starts at 1306 ... - on load all runcores are notified to use the new oplib function or address table What happens if the opcode library is rebuilt with more ops after the bytecode using it is compiled and frozen to disk? Even if the new ops are numbered (correctly) after the existing ops, if the loader just allocates op numbers on loading continuing after the last op number of the previously loaded library, than as soon as any op library gains an extra op, anything loading after it goes horribly wrong. (Likewise if an op library keeps the same number of ops, but itself gains a new dependency on an external op library) How or from where is the second stage then done? Currently it would look like this: loadlb P1, myops_ops fortytwo I0 Cloadlib calls FParrot_load_lib which calls FParrot_lib_%s_load. This would call back and run Coplib_register. That installs the opcode dispatch tables. The assembler must do the same thing (as it does with dynamic PMCs) to get the same opcode numbers (or class enums respectively). We could actually defer installing the opcode dispatch table at runtime, but we must reserve the opcode number range, and the assembler must at least be able to query the dynamic lib for valid opcode names. When the first unknown opcode is to be run, then the real functions could be put in place. Or am I getting confused and all this lookup is done by name? Nicholas Clark
[perl #24185] [PATCH] JIT debugging on AIX
# New Ticket Created by Adam Thomason # Please include the string: [perl #24185] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24185 Here's the beginning of support for debugging the JIT core with the native compiler on AIX. This patch implements a replacement for jit_debug.c that emits XCOFF-compatible stabs in order to placate the AIX assembler. It's not quite ready for merging; I'm posting it in the hope that somebody might have some insights on how to make the debugger cooperate. I'm fairly certain I'm assembling the stabs object correctly since they all show up in the symbol table of the assembled object, but at the moment gdb seems unwilling to import those symbols using add-symbol-file (i.e., it won't let me step into jit_func). On the other hand, GNU 'objdump -g' doesn't see them either, so the XCOFF stabs support in the GNU tools may just be lacking, in which case I'll have to fall back to the native debugger. If anybody could offer suggestions on how to make gdb or dbx behave (or any other advice on PPC JIT debugging), I'd be very appreciative. -- Adam Thomason [EMAIL PROTECTED] -- attachment 1 -- url: http://rt.perl.org/rt2/attach/65929/49246/f71d14/jit.patch jit.patch Description: jit.patch
Re: cvs commit: parrot/io io.c io_buf.c
At 11:23 PM 10/10/2003 +0100, Nicholas Clark wrote: On Fri, Oct 10, 2003 at 05:55:11PM -0400, Melvin Smith wrote: Which ones? The PIOCTL ones are, for a lack of current interface, a way for interfacing to the lower level IO system through a catchall opcode. It can be anything from setting terminal modes, buffering, separator characters, the list goes on. Sorry. Wasn't clear. The PIOCTL macros are (to me) the correct way of doing something. -6 and -3 are magic numbers. They have no context as to what they might be. Eep, I misread it, you were clear. That was just debugging I left in. Have we defined the standard way for error reporting in Parrot. At one time we had talked of having an errno for each interpreter? Maybe now is the time to standardize it. -Melvin
