[perl #29994] [BUG] "loadlib $P0, varname" not working correctly
Jens Rieks
# Please include the string: [perl #29994]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29994 >
% cat error.imc
.sub _main @MAIN
.local string na123me
na123me = "/foo"
loadlib $P0, na123me
end
.end
% ./parrot -o error.pbc error.imc
Couldn't load 'runtime/parrot/a123m': runtime/parrot/a123m: cannot open shared
object file: No such file or directory
This is caused by imcc/parser_util.c:INS, where a test is done to check if the
current instruction is "loadlib"; if it is, the second argument is treat as a
string; this fails if it actually is a variable name.
Leopold Toetsch
> % cat error.imc
> .sub _main @MAIN
> .local string na123me
> na123me = "/foo"
> loadlib $P0, na123me
> end
> .end
> % ./parrot -o error.pbc error.imc
> Couldn't load 'runtime/parrot/a123m':
The parser currently loads extensions at compile time to be able to load
in new PMC types. This of course fails with variables.
I can see some ways to fix that:
- allow only string constants for loadlib
- don't load extensions at compile time, so that dynamic PMCs have to be
created with
$I0 = find_type "Foo"
$P0 = new $I0
- just don't try to load the lib, if it's name isn't a string constant
leo
Dan Sugalski
>- don't load extensions at compile time, so that dynamic PMCs have to be
> created with
>
> $I0 = find_type "Foo"
> $P0 = new $I0
Option two here would be the right one.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> At 9:51 AM +0200 6/2/04, Leopold Toetsch wrote:
>>- don't load extensions at compile time, so that dynamic PMCs have to be
>> created with
>>
>> $I0 = find_type "Foo"
>> $P0 = new $I0
> Option two here would be the right one.
For dynamic PMC classes and NCI yes. *But* what about dynamic opcode
libs? The PASM/PIR compilers have to load in the lib to be able to emit
the opcode number. Should we use a different opcode for the latter?
leo
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
>> At 9:51 AM +0200 6/2/04, Leopold Toetsch wrote:
>>>- don't load extensions at compile time, so that dynamic PMCs have to be
>>> created with
>>>
>>> $I0 = find_type "Foo"
>>> $P0 = new $I0
>
>> Option two here would be the right one.
>
>For dynamic PMC classes and NCI yes. *But* what about dynamic opcode
>libs? The PASM/PIR compilers have to load in the lib to be able to emit
>the opcode number.
Well... not necessarily. The original scheme was for the opcode
loading code to specify what numbers the loaded opcodes would get for
the compilation unit in question.
>Should we use a different opcode for the latter?
I think we need a different scheme for loadable opcode libs, yeah. We
need more metainformation, either at load or at compile time,
possibly both. I think, though, that the compile time information can
be specified completely in the PIR code. Whether we want to or not is
a separate issue, of course, but I think we're going to want to do so.
Might look something like:
.library foo.ops {
.op acosh
.op asech
.op atanh
}
or just go with a .library/.end pair. I don't much care, it's not
that big a deal. It's enough to give the pir compiler what it needs
to map op names to op numbers, and then we need to have a metadata
section in the bytecode file to tell the loader what it needs to do
to build the opcode tables when the bytecode's loaded in and the sub
pmcs are instantiated.
Leopold Toetsch
> Well... not necessarily. The original scheme was for the opcode
> loading code to specify what numbers the loaded opcodes would get for
> the compilation unit in question.
Opcode numbers only aren't sufficient. The compiler checks argument
count and types too. It needs additionally the PARROT_ARGDIR_* flags for
life analysis and PARROT_JUMP_* for generating basic blocks.
The whole information is in the C<struct op_info_t>, which is loaded in
at compile time. Having a totally different scheme for loadable ops
isn't really a good thing.
*If* we allow a different order for loaded ops at compile vs run time,
we need additional information in the metadata, to be able to relocate
the range of dynamic ops. It's a matter of taste, if we allow that or if
we just state: <loadlib> opcodes for dynamic oplibs have to be seen by
the compiler in runtime order.
I'd for now go with option three which was: don't load dynamic libs
which aren't constant strings.
BTW: is it really needed to specify a dynamic extension by variable
name?
leo
Leopold Toetsch
> At 9:50 AM +0200 6/3/04, Leopold Toetsch wrote:
>>Dan Sugalski <d...@sidhe.org> wrote:
>>
>>> Option two here would be the right one.
>>
>>For dynamic PMC classes and NCI yes. *But* what about dynamic opcode
>>libs? The PASM/PIR compilers have to load in the lib to be able to emit
>>the opcode number.
I've for now disabled C<loadlib> at compile time for variables. We still
need something for dynamic opcode libs.
I think that a separate opcode would be simplest:
load_ops Px, "myops" # constant filename only, compile time
loadlib Px, lib # runtime
leo
Klaas-Jan Stol via RT
> Dan Sugalski <d...@sidhe.org> wrote:
> > At 9:50 AM +0200 6/3/04, Leopold Toetsch wrote:
> >>Dan Sugalski <d...@sidhe.org> wrote:
> >>
> >>> Option two here would be the right one.
> >>
> >>For dynamic PMC classes and NCI yes. *But* what about dynamic opcode
> >>libs? The PASM/PIR compilers have to load in the lib to be able to emit
> >>the opcode number.
>
> I've for now disabled C<loadlib> at compile time for variables. We still
> need something for dynamic opcode libs.
>
> I think that a separate opcode would be simplest:
>
> load_ops Px, "myops" # constant filename only, compile time
> loadlib Px, lib # runtime
>
> leo
>
I checked this bug on windows, and apparently, the loadlib op works. See
for an example the attachment. It loads the library libnci_test, which
is included in the Parrot distr.
Both
$P0 = loadlib myLib
as
$P0 = loadlib 'libnci_test'
work.
However, something else seems to be wrong: when loading a non-existent
library (as in the example), no error message/exception is shown/raised.
I think this should be the case, although I don't really know the specs
for that. (it would make sense to do so, though)