[m-dev.] Performance of collect

Fergus Henderson fjh at cs.mu.OZ.AU
Tue Sep 26 02:10:15 AEDT 2000


On 25-Sep-2000, Erwan Jahier <Erwan.Jahier at irisa.fr> wrote:
> Fergus wrote:
> | On 25-Sep-2000, Erwan Jahier <Erwan.Jahier at irisa.fr> wrote:
> | > Yes, I have understood that. My idea was to use the LLDS back-end (or whatever
> | > back-end) to compile the Mercury program to be monitored, and to use the MLDS
> | > back-end to compile the monitor (the collect module).
> | 
> | Oh, I see what you mean.  Hmm...
> | 
> | > Currently, it seems to be impossible to mix code that have been compiled in
> | > different grades; what are the reasons for that? Do those reasons still hold for
> | > the MLDS back-end?
> | 
> | The reasons vary a bit.  The main reason is that the linkage (naming)
> | convention and calling conventions differ between different grades.
> | That doesn't apply *directly* in your case, since the collect code is
> | only called from C, not from Mercury.  However, the collect code calls
> | the Mercury standard library.  To make your idea work, you'd therefore
> | need to link with two different copies of the standard library and
> | runtime, one in an LLDS grade and one in an MLDS grade.  That would
> | almost certainly cause problems.  I don't think it is going to work.
> 
> That's a little bit... sad.
> 
> But I would still like to have a try, at least to be able to do some 
> measurements with monitor that don't use libraries.
> 
> So the original program is compiled in asm_fast.gc grade, and  the collect
> module in hlc.gc grade. I have modified browser/collect_lib.m so that it looks
> for the initilaze/1 and filter/4 with the hlc naming convention (I have edited
> collect.c to find how they were called). Unfortunaltely, the dlopen still
> fails:
> 
> ** dlopen failed: ld.so.1: ./hello: fatal : erreur de réadressage : fichier ./
> ** collect.so : symbole mercury__private_builtin__builtin_compare_string_3_p_0 :
> ** symbole référencé introuvable

What's the error message when you set the locale (LC_ALL or LANG environment
variable) to "C"?  It's hard enough to debug these things in English,
let alone in French! ;-)

> I guess it is again a naming convention problem, but I don't quite understand
> where it is coming from (this symbol does appear in collect.c). Do you have an
> idea?

Probably you have a call to compare/3 in collect.m with a string argument.
This may occur in the automatically-generated clauses for compare/3
for the types defined in collect.m.

> Incidently, when do you plan to add support for debugging for that back-end?

Well, it's a fairly big task... it's a long-term goal, but I don't have any
immediately plans to do it any time soon.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list