[Ecls-list] Arglist?

[Matthew Mondor]

On Mon, 8 Feb 2010 09:09:46 +0100
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> ECL does not normally store information about a compiled function lambda
> list, just for economy reasons -- it is not used anywhere in ECL, not even
> in the debugger because function arguments are directly registered by the
> function at run time if debug settings are large enough.
> 
> If such a function is really needed we would have to add an option to the
> compiler so that it stores the lambda list or even the function code, though
> the latter would be questionable, given the bloat that would result.  In any
> case it would not be that difficult.

Indeed if that was implemented it probably would be good to easily
disable the feature.

I see three different methods that information could be stored/accessed:

The simplest approach, which is also the best performance-wise, but
also requires more runtime memory, would be to store the lambda lists
as standard static data and rely on the standard loader to also load it.

If it's less performance-critical, it would probably be possible to
store those as part of a separate indexed file which could be randomly
accessed (mapped, or seek/read).  Despite the extra runtime overhead,
the buffer cache would speed up frequently accessed pages (or we could
even load completely said file and index it once, so it's then accessed
with high performance).

Another possibility, but which would probably have to rely on some type
of object format agnostic library such as libBFD, would be to store
those lambda lists as part of a special note section, or even perhaps
in the DWARF format.  In the later case, perhaps it'd even be possible
to force compiler+linker debugging flags (i.e. -g) when the feature is
enabled, and generate the lambda-list lazily from the stored debugging
information?

The advantage of the two last approaches would be the possibility to
add the complete function source as well, since it doesn't have to be
loaded in memory unless the lambda-list feature is used (and if it's
loaded using random access, the memory overhead is small, but it
depends on files being available at runtime).
-- 
Matt