Re: Strangeness with '.sub' in macros

2003-12-31 Thread Leopold Toetsch
Bernhard Schmalhofer [EMAIL PROTECTED] wrote:
 When a macro contains a '.sub' call, and that macro is used twice, then I get
 a 'memory error'.

Confirmed. The segfault is in expand_pcc_sub_call(), the sub SymReg is
NULL on the second expansion.

 How can I tell 'parrot' to dump a core file?

Tell your OS to dump core :)
$ man bash
/ulimit

$ ulimit -c 2

 CU, Bernhard

leo


Re: Strangeness with '.sub' in macros

2003-12-30 Thread Harry Jackson
Bernhard Schmalhofer wrote:
Hi,

Could sombody test the attached script on another machine?
I'm working here on a Linux laptop:
I am geting a seg fault. Its fine when the second call is commented out.

I am not sure if any of the following is any use to you.

The follwoing PASM was part generated from your IMC, I added the bits
between ###. This calls the sub twice I am not sure if it is any use
to you. Please see some output from GDB at the end.
_main:
set P16, P1
newsub P16, 45, _dummy
@pcc_sub_call_2:
set I5, 1
set P0, P16
set I0, 1
set I1, 0
set I2, 0
set I3, 0
savetop
invokecc
restoretop
###
set I5, 2
set I0, 1
set I1, 0
set I2, 0
set I3, 0
savetop
invokecc
restoretop
###
end
_dummy:
print dummy was called with: 
print I5
print \n
@pcc_sub_ret_25:
set I0, 1
set I1, 0
set I2, 0
set I3, 0
set I4, 0
invoke P1


[EMAIL PROTECTED] pbin]$ gdb parrot
GNU gdb Red Hat Linux (5.1-1)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-redhat-linux...
(gdb) b runops_jit
Breakpoint 1 at 0x8075236: file src/interpreter.c, line 422.
(gdb) run -j -d test.pbc
Starting program: /home/parrot/bin/parrot -j -d test.pbc
[New Thread 1024 (LWP 17090)]
[New Thread 2049 (LWP 17091)]
[New Thread 1026 (LWP 17092)]
Address of base segment is (nil)
Address of base segment is (nil)
*** Parrot VM: JIT core ***
*** Parrot VM: Setting up ARGV array in P5.  Current argc: 1 ***
0: test.pbc
[Switching to Thread 1024 (LWP 17090)]
Breakpoint 1, runops_jit (interpreter=0x8214a08, pc=0x400180d0) at
src/interpreter.c:422
422 jit_f jit_code = (jit_f) D2FPTR(init_jit(interpreter, pc));
(gdb) n
423 (jit_code) (interpreter, pc);
(gdb) n
Address of base segment is 0x400180d0
dummy was called with: 1
425 return NULL;
(gdb) n
426 }
(gdb) n
runops_int (interpreter=0x8214a08, offset=0) at src/interpreter.c:633
633 interpreter-lo_var_ptr = old_lo_var_ptr;
(gdb) n
634 if ((interpreter-resume_flag  RESUME_RESTART) 
(gdb) n
553 while (interpreter-resume_flag  RESUME_RESTART) {
(gdb) n
638 }
(gdb) n
runops_ex (interpreter=0x8214a08, offset=0) at src/interpreter.c:652
652 if (interpreter-resume_flag  RESUME_ISJ) {
(gdb) n
679 }
(gdb) n
runops (interpreter=0x8214a08, offset=0) at src/interpreter.c:709
709 }
(gdb) n
Parrot_runcode (interpreter=0x8214a08, argc=1, argv=0xb980) at
src/embed.c:514
514 }
(gdb) n
main (argc=1, argv=0xb980) at imcc/main.c:551
551 Parrot_destroy(interpreter);
(gdb) n
552 if (output)
(gdb) n
554 mem_sys_free(interpreter-imc_info);
(gdb) n
555 Parrot_exit(0);
(gdb) n
*** Parrot VM: Dumping GC info ***
Total memory allocated = 139264
DOD runs = 0
Collect runs = 0
Collect memory = 0
Active PMCs = 1024
Active buffers = 6144
Total PMCs = 1024
Total buffers = 6144
Header allocations since last collect = 7
Memory allocations since last collect = 1
Program exited normally.
(gdb)
Harry Jackson



Re: Strangeness with '.sub' in macros

2003-12-30 Thread Melvin Smith
At 05:45 PM 12/30/2003 +0100, Bernhard Schmalhofer wrote:
Hi,

I have been playing around with 'libpcre' for Parrot m4.
For some reason I couldn't compile two regular expressions in the same
PIR script.
I created a sample C program and that worked like it should.
It looks like the error has nothing to do with 'libpcre'. So I boiled down
my code to a small test script.
When a macro contains a '.sub' call, and that macro is used twice, then I get
a 'memory error'.
[EMAIL PROTECTED]:~/devel/Parrot/parrot/languages/m4 ../../parrot
t/regex/macro_used_twice.imc
Speicherzugriffsfehler
Could sombody test the attached script on another machine?
I'm working here on a Linux laptop:
Two answers here.

1) We probably have a bug in macro expansion
2) Dan has declared that macros are coming out of IMCC. (Mainly because I 
told him
 I don't want them and they make the lexer more complicated than I want it 
to be.. and..
 macros are less useful for compilers than people hand-writing IMC code)

I prefer macros to be a part of a preprocessor tool external to the builtin 
IMC language.
If enough people really have strong opinions on macros, now is the time to 
voice it, because
otherwise I'm removing them.

-Melvin