library loading cleanup
Leopold Toetsch
some obscure uninitialized memory bugs, somewhere hidden inside library
loading (see also #37814 and the attached valgrind log).
I've been looking up and down through the code, but there is no obvious
problem. E.g. the invalid reads are *inside* of allocated memory, we
don't have too short buffers, ..
Anyway, all the code paths used during library loading need some
cleanup.
1) use STRING* everywhere
We start with and opcode like 'load_bytecode' or 'loadlib', which all
have STRING * arguments. Then STRINGs are converted to C-strings,
concatenated, converted to STRING (because Parrot_stat_info_intval
takes a STRING) and so on. And we might need a STRING* anyway to open
files (e.g. windows with UCS2 file names).
2) I'm very much inclined to remove the Win32 special casing (see also
r8673)
There are already 2 possibilities to specify the runtime prefix (where
libs are searched).
a) perl Configure --prefix=foo
This sets the built in prefix for the installable executable
b) set the evironment variable PARROT_RUNTIME
If a) isn't appropriate, because Parrot is installed into some
different place, then the install program can still use method b).
3) unify uninstalled and installed library paths. Thanks to rafl, we
have have now docs/dev/fhs.pod, which describes the desired runtime
layout.
4) make the search paths extendible at runtime, a la 'push @INC, path'.
Comments welcome. Also if someone wants just to do the cleanup, please
say so, but it is really urgent.
leo
Jerry Gay
> 2) I'm very much inclined to remove the Win32 special casing (see also
> r8673)
>
> There are already 2 possibilities to specify the runtime prefix (where
> libs are searched).
> a) perl Configure --prefix=foo
> This sets the built in prefix for the installable executable
> b) set the evironment variable PARROT_RUNTIME
>
> If a) isn't appropriate, because Parrot is installed into some
> different place, then the install program can still use method b).
>
operating systems, i'll make sure it's implemented correctly on
windows. this will probably require no more than a few changes to the
hints files in the configure system. if it helps improve the quality
of the the library loading code, i'm all for it.
~jerry
Leopold Toetsch
On Dec 6, 2005, at 16:08, jerry gay wrote:
> On 12/6/05, Leopold Toetsch <l...@toetsch.at> wrote:
>> 2) I'm very much inclined to remove the Win32 special casing (see also
>> r8673)
>>
>> There are already 2 possibilities to specify the runtime prefix (where
>> libs are searched).
>> a) perl Configure --prefix=foo
>> This sets the built in prefix for the installable executable
>> b) set the evironment variable PARROT_RUNTIME
>>
>> If a) isn't appropriate, because Parrot is installed into some
>> different place, then the install program can still use method b).
>>
> as long as there's a workable, documented solution that covers all
> operating systems, i'll make sure it's implemented correctly on
> windows.
I've now added c) to the list of alternatives that is (from perldoc
src/library.c):
lib_paths = [
[ "runtime/parrot/include", ... ], # paths for
.include 'file'
[ "runtime/parrot/library", ... ], # paths for
load_bytecode
[ "runtime/parrot/dynext", ... ], # paths for loadlib
[ ".so", ... ] TODO # list of shared
extensions
]
If the platform defines
#define PARROT_PLATFORM_LIB_PATH_INIT_HOOK the_init_hook
if will be called as a function with this prototype:
void the_init_hook(Interp*, PMC *lib_paths);
Platform code may add, delete, or replace search path
entries as
needed. See also include/parrot/library.h for
"enum_lib_paths".
HTH
leo