Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Waldo Bastian]

On Tuesday 04 December 2001 04:40 am, Bernhard Rosenkraenzer wrote:
> FYI
>
> ---------- Forwarded message ----------
> Date: Mon, 3 Dec 2001 17:17:55 +0100
> From: Jakub Jelinek <jakub@redhat.com>
> To: <some-internal-list@redhat.com>
> Subject: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC
> 3.0.3: Bugs to Fix])
>
> Hi!
>
> If you want dynamic cast (and that's just one thing) to work with dlopen in
> gcc3+, you need to use RTLD_GLOBAL. (Don't get confused by Nathan not
> understanding what if and only if means).

That's pretty bad because loading (dlopen'ing) parts with RTLD_GLOBAL is 
asking for trouble. There is no way that we can guarantee that one part 
doesn't by chance use the same name for some class/symbols as another part, 
since parts may get developed independently of each other.

We are already running into trouble with the flash plugin colliding with 
OpenGL (both define "DisplayList") and things like this aren't helping the 
situation.

The alternative, banning RTTI from KDE, isn't very attractive either.

Cheers,
Waldo

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[shaheed]

Hi

> > If you want dynamic cast (and that's just one thing) to work with dlope
> > in gcc3+, you need to use RTLD_GLOBAL. (Don't get confused by Nathan no
> > understanding what if and only if means)

> That's pretty bad because loading (dlopen'ing) parts with RTLD_GLOBAL i
> asking for trouble. There is no way that we can guarantee that one par
> doesn't by chance use the same name for some class/symbols as another part
> since parts may get developed independently of each other

> We are already running into trouble with the flash plugin colliding wit
> OpenGL (both define "DisplayList") and things like this aren't helping th
> situation

> The alternative, banning RTTI from KDE, isn't very attractive either

Note that there is at least one use of RTTI in the MS Word import filter for 
KWord. It *could* be eliminated in favour of an alternative hack if required, 
but RTTI is needed at present at least

Thanks, Shahee

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Joe Buck]

Jakub Jelinek <jakub@redhat.com> wrote:
> > If you want dynamic cast (and that's just one thing) to work with dlopen in
> > gcc3+, you need to use RTLD_GLOBAL. (Don't get confused by Nathan not
> > understanding what if and only if means).

Waldo Bastian wrote:
> That's pretty bad because loading (dlopen'ing) parts with RTLD_GLOBAL is 
> asking for trouble. There is no way that we can guarantee that one part 
> doesn't by chance use the same name for some class/symbols as another part, 
> since parts may get developed independently of each other.
> 
> We are already running into trouble with the flash plugin colliding with 
> OpenGL (both define "DisplayList") and things like this aren't helping the 
> situation.

But that causes an interesting problem.  You say that you don't want to
use RTLD_GLOBAL because someone might duplicate a class name (say,
"DisplayList").  Of course, this violates the one-definition rule, but
let's ignore that for a moment.

But if you want to allow multiple definitions of the same class, then
I don't see what

	dynamic_cast<DisplayList*>(foo)

is supposed to mean.  One possible definition is for the strings of all
base classes of foo to be checked for a match.  But what if that turns out
to be a different DisplayList than the one the current compilation unit
knows about?  Also there is a speed penalty to be paid if we must do this
string-compare, possibly a substantial one.  Certainly there are hashing
techniques that could be used to make the lookup faster, but we're between
a rock and a hard place: we signed up to implement a standard ABI that
multiple compiler vendors agreed on, and it puts constraints on the RTTI
implementation.  Even if the g++ team agrees to solve it for you, it would
just mean that KDE can't be built by the other compilers, like Intel's,
SGI's, or HP's.

> The alternative, banning RTTI from KDE, isn't very attractive either.

What if you only use RTLD_GLOBAL for those libraries that define base
classes that you'll want to do RTTI with?  Or use it everywhere except
with libraries that you know are problematic and sloppy with name spaces,
like the flash plugin and OpenGL.

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Dirk Mueller]

On Die, 04 Dez 2001, Joe Buck wrote:

> But that causes an interesting problem.  You say that you don't want to
> use RTLD_GLOBAL because someone might duplicate a class name (say,
> "DisplayList").  Of course, this violates the one-definition rule, but
> let's ignore that for a moment.

Point taken for the RTLD_GLOBAL part, but why do we need RTLD_NOW in order 
to make RTTI work, as the original posting pointed out ?

I think lazy symbol resolving is the least thing an ABI should be capable of 
when living in the 21th century..


Dirk

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Mark Mitchell]

--On Wednesday, December 05, 2001 01:35:51 AM +0100 Dirk Mueller 
<dmuell@gmx.net> wrote:

> On Die, 04 Dez 2001, Joe Buck wrote:
>
>> But that causes an interesting problem.  You say that you don't want to
>> use RTLD_GLOBAL because someone might duplicate a class name (say,
>> "DisplayList").  Of course, this violates the one-definition rule, but
>> let's ignore that for a moment.
>
> Point taken for the RTLD_GLOBAL part, but why do we need RTLD_NOW in
> order  to make RTTI work, as the original posting pointed out ?

I don't think you should (I would think RTLD_LAZY would be OK), but I
am not the world's biggest dynamic linking expert...

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Waldo Bastian]

On Tuesday 04 December 2001 02:50 pm, Joe Buck wrote:
> > The alternative, banning RTTI from KDE, isn't very attractive either.
>
> What if you only use RTLD_GLOBAL for those libraries that define base
> classes that you'll want to do RTTI with?  Or use it everywhere except
> with libraries that you know are problematic and sloppy with name spaces,
> like the flash plugin and OpenGL.

The problem that we had was with things like templates. If two plugins use the 
same template, they will get the same symbol-names. When the symbols are 
loaded in the global namespace, it can happen that plugin A resolves against 
the symbols of plugin B. When you now unload plugin B you will get a crash 
the next time you access plugin A.

(Unloading plugins is a risky business anyway, because with 2.9x the process 
will crash on exit when there were static objects declared within 
function-scope in the plugin.)

To what _extent_ does linking without RTLD_GLOBAL break RTTI? Looking at 
PR3993 breakage there seems to happen because the module that does the 
dlopen'ing doesn't strongly define class B (how do you call that, "class B 
isn't being emitted"?)  That situation could be prevented most of the time I 
think. (I believe such classes also have a negative impact on prelinking)

Wouldn't then the only remaining problem be classes that are defined in both 
plugin A and plugin B (e.g. template) but aren't defined in the module that 
loads them? RTTI-wise such classes would be considered distinct then if I 
understand correctly?

Franz: You described PR3993 as "another KDE2 blocking bug", where does this 
behaviour break stuff in KDE?

Cheers,
Waldo

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Simon Hausmann]

On Sun, Dec 09, 2001 at 11:40:43PM -0800, Waldo Bastian wrote:
> To what _extent_ does linking without RTLD_GLOBAL break RTTI? Looking at 
> PR3993 breakage there seems to happen because the module that does the 
> dlopen'ing doesn't strongly define class B (how do you call that, "class B 
> isn't being emitted"?)  That situation could be prevented most of the time I 
> think. (I believe such classes also have a negative impact on prelinking)

I think both 'modules', the dlopen'ing app as well as the shared
library do contain the actual RTTI info. However (see also comments
on PR4993) neither the app has been linked with --export-dynamic nor
is the shared library dlopen'ed with RTDL_GLOBAL, hence the weak rtti
symbols in the shared library aren't resolved to the existing onces
in the app -> with duplicated RTTI info for the same class the
pointer comparison fails.

> Franz: You described PR3993 as "another KDE2 blocking bug", where does this 
> behaviour break stuff in KDE?

The regular expression editor is one example (it is loaded
dynamically in khtml/kate/klipper, exactly like in 3993) , some of
the texteditor interfaces in kdelibs/interfaces another one. If we
don't want to use RTLD_GLOBAL I see too solutions from our side:

1) Use intermediate shared libraries. Like the regular expression
   editor component gets another shared library to which all apps
   using the component would have to link against. This doesn't
   scale very well for a big amount of components.

2) Don't use C++ RTTI to determine whether the given object inherits
   from the pure base class but use Qt RTTI instead (qt_cast) .
   Syntactically not as beautiful (we could hide it behind a d-cast
   like template though) it does quite the same job as when C++ rtti
   falls back on the string comparison approach. (which while being
   slower should still be fine for KDE as we usually don't do that
   casting in inner loops or other time critical places - I think
   functionality is here more important)

Simon

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Lubos Lunak]

On Mon 10. December 2001 09:39, Simon Hausmann wrote:
[snip]
>
> The regular expression editor is one example (it is loaded
> dynamically in khtml/kate/klipper, exactly like in 3993) , some of
> the texteditor interfaces in kdelibs/interfaces another one. If we
> don't want to use RTLD_GLOBAL I see too solutions from our side:
>
> 1) Use intermediate shared libraries. Like the regular expression
>    editor component gets another shared library to which all apps
>    using the component would have to link against. This doesn't
>    scale very well for a big amount of components.
>
> 2) Don't use C++ RTTI to determine whether the given object inherits
>    from the pure base class but use Qt RTTI instead (qt_cast) .
>    Syntactically not as beautiful (we could hide it behind a d-cast
>    like template though) it does quite the same job as when C++ rtti
>    falls back on the string comparison approach. (which while being
>    slower should still be fine for KDE as we usually don't do that
>    casting in inner loops or other time critical places - I think
>    functionality is here more important)
>

 Maybe I'm missing something obvious, but how about this one?
   3) Persuade gcc folks to add compiler switch that makes gcc use string 
comparing when doing rtti, and simply compile whole KDE with this switch 
turned on.

 It seems to be very similar to 2), with some advantages, like working also 
for classes not inheriting from QObject without problems. Also whether 
dynamic_cast etc. uses just pointer comparing or string comparing 
shouldn't(?) affect the ABI, so I don't see any serious problem with it.

-- 
 Lubos Lunak
 llunak@suse.cz ; l.lunak@kde.org
 http://dforce.sh.cvut.cz/~seli

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Mark Mitchell]

>    3) Persuade gcc folks to add compiler switch that makes gcc use string
> comparing when doing rtti, and simply compile whole KDE with this switch
> turned on.

All code in the application -- including the C++ run-time library --
needs to be compiled the same way, so you would have to rebuild
everything to do this.

In general, I will argue against any such change.

Mixing C++ and dlopen w/o RTLD_GLOBAL is fundamentally wrong.

The right model is that this is like using an uninitialized
variable.  It might work somtimes, but it is a completely horrible
thing to do, totally unportable, and will succeed or fail based on
minor changes elsewhere in the code.

It would be a disservice for us to add features that try to accomodate
this; they cannot be made to work reliably and so all they would do
is create a temptation for people to write code that will not work.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC

[Joe Buck]

> 
> >    3) Persuade gcc folks to add compiler switch that makes gcc use string
> > comparing when doing rtti, and simply compile whole KDE with this switch
> > turned on.

Mark writes:
> All code in the application -- including the C++ run-time library --
> needs to be compiled the same way, so you would have to rebuild
> everything to do this.

In this case, that isn't clear to me.  All code needs to be compiled the
same way if the flag in question produces an incompatible ABI, but I'm
not sure it would necessarily be true in this case.  It might be possible
to have a design that would only require special treatment for code
containing RTTI operations where types cross a dynamic library boundary,
but to still use the same standard library.

Just the same, it's not reasonable for the KDE folks to expect the gcc
folks to design such a feature for them.  It's not C++.  KDE isn't going
to work with any of the other x86-on-Linux compilers either (SGI, Intel)
if it requires such a feature.

> Mixing C++ and dlopen w/o RTLD_GLOBAL is fundamentally wrong.

This goes too far.  In many cases it is very useful; we certainly used the
technique heavily in the Ptolemy project, and made it work on many Unix
flavors plus Windows (however, the use was more restricted: it allowed the
dynamic loading of derived classes for which the base classes were already
in the core application with globally available symbols, and builtin RTTI
operations like dynamic_cast were not used).

What's broken in the KDE case is that two contradictory things are being
requested: RTTI assuming a global type system, and dynamic loading
assuming private type systems.

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC

[Mark Mitchell]

--On Monday, December 10, 2001 11:14:30 AM -0800 Joe Buck 
<jbuck@synopsys.COM> wrote:

>>
>> >    3) Persuade gcc folks to add compiler switch that makes gcc use
>> >    string comparing when doing rtti, and simply compile whole KDE with
>> > this switch turned on.
>
> Mark writes:
>> All code in the application -- including the C++ run-time library --
>> needs to be compiled the same way, so you would have to rebuild
>> everything to do this.
>
> In this case, that isn't clear to me.  All code needs to be compiled the
> same way if the flag in question produces an incompatible ABI, but I'm
> not sure it would necessarily be true in this case.

This is exactly the kind of thing we shouldn't tell people. :-)

It is true that if you use strcmp with class data structures that
expect address comparison, you are safe.  The other direction is not
safe.  So, if there is ever a use of RTTI or exception-handling in
the code that was compiled without the special switch, but applying
to classes from the code compiled with the special switch, you have
problems.

>> Mixing C++ and dlopen w/o RTLD_GLOBAL is fundamentally wrong.
>
> This goes too far.

Well, perhaps.  See below.

> What's broken in the KDE case is that two contradictory things are being
> requested: RTTI assuming a global type system, and dynamic loading
> assuming private type systems.

That's the *specific* thing that's going wrong this time.  There are
lots of other things that might go wrong, and even enumerating them
is difficult.  Nathan already mentioned the fact that the same
template instantiation may have multiple addresses.  That applies
to static data members, not just functions; this is a potentially
catastrophic problem.

(The compiler is also allowed to depend on function address comparisions 
when optimizing, even if the code does not do so explicitly:

  int id(int i) { return i; }

  void f(int (*fp)(int), int i) {
    return fp(i);
  }

could be transformed into:

  void f(int (*fp)(int), int i) {
    if (fp == &id) return i;
    else return fp(i);
  }

We don't currently ever do this, but we could.)

There are other objects with vague linkage besides RTTI data, such as
static data in inline functions with external linkage.

Remember that your code need not have these constructs; all that is
necessary is that you #include something that does, including something
from the standard library.

Yes, if you really, really know what you are doing and you are willing
to write code that is unportable, or that does not make use of many
language features, and you know the ABI, you may be able to get away
with this.

You are, however, playing with fire.

I certainly do not think that G++ should be obliged to make any
guarantees about this situation.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC

[Joe Buck]

> Yes, if you really, really know what you are doing and you are willing
> to write code that is unportable, or that does not make use of many
> language features, and you know the ABI, you may be able to get away
> with this.
> 
> You are, however, playing with fire.

No kidding.  Elaborate reference counting mechanisms to make sure we don't
delete code objects where we still have data objects whose vtables don't
point there, the quirks of five completely distinct dynamic linking
systems on different OSes, etc.  On the other hand, I used g++ in 1990.
That was fire, man.

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Alexandre Oliva]

On Dec 10, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

>> 3) Persuade gcc folks to add compiler switch that makes gcc use string
>> comparing when doing rtti, and simply compile whole KDE with this switch
>> turned on.

> All code in the application -- including the C++ run-time library --
> needs to be compiled the same way, so you would have to rebuild
> everything to do this.

Err...  Wouldn't it be enough to link with a modified version of the
object file that implements rtti comparison?  Or are such comparisons
ever inlined in the generated code?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Mark Mitchell]

--On Tuesday, December 11, 2001 03:09:53 PM -0200 Alexandre Oliva 
<aoliva@redhat.com> wrote:

> On Dec 10, 2001, Mark Mitchell <mark@codesourcery.com> wrote:
>
>>> 3) Persuade gcc folks to add compiler switch that makes gcc use string
>>> comparing when doing rtti, and simply compile whole KDE with this switch
>>> turned on.
>
>> All code in the application -- including the C++ run-time library --
>> needs to be compiled the same way, so you would have to rebuild
>> everything to do this.
>
> Err...  Wouldn't it be enough to link with a modified version of the
> object file that implements rtti comparison?  Or are such comparisons
> ever inlined in the generated code?

They are typically inlined.  From <typeinfo>:

  class type_info {
    ...
    bool operator==(const type_info& __arg) const
    { return __name == __arg.__name; }
  };

There you have it.  We certainly want to inline these; they are
almost free.

The point I tried to make yesterday, but apparently somewhat
unsuccessfully, is that RTTI is only the tip of the iceberg.
You might be able to fix this -- but you can't fix all the
problems, and it's not easy to specify what subset of the
language you can support.

It's a mistake to try.  It's much better to tell your customers
how to use your product successfully than to encourage them to
use a technique likely to fail.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Richard Henderson]

On Sun, Dec 09, 2001 at 11:40:43PM -0800, Waldo Bastian wrote:
> ... it can happen that plugin A resolves against 
> the symbols of plugin B. When you now unload plugin B you will get a crash 
> the next time you access plugin A.

FWIW, this should be fixed in glibc 2.2.4.  If A references B, 
then an unload of B will not actually occur until A unloads.


r~

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Andreas Schwab]

Richard Henderson <rth@redhat.com> writes:

|> On Sun, Dec 09, 2001 at 11:40:43PM -0800, Waldo Bastian wrote:
|> > ... it can happen that plugin A resolves against 
|> > the symbols of plugin B. When you now unload plugin B you will get a crash 
|> > the next time you access plugin A.
|> 
|> FWIW, this should be fixed in glibc 2.2.4.  If A references B, 
|> then an unload of B will not actually occur until A unloads.

IIRC there were some bugs left in this area even in 2.2.4, but they should
be fixed in current CVS.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Nathan Sidwell]

Waldo Bastian wrote:
> 
> On Tuesday 04 December 2001 02:50 pm, Joe Buck wrote:
> > > The alternative, banning RTTI from KDE, isn't very attractive either.
> >
> > What if you only use RTLD_GLOBAL for those libraries that define base
> > classes that you'll want to do RTTI with?  Or use it everywhere except
> > with libraries that you know are problematic and sloppy with name spaces,
> > like the flash plugin and OpenGL.
> 
> The problem that we had was with things like templates. If two plugins use the
> same template, they will get the same symbol-names. When the symbols are
> loaded in the global namespace, it can happen that plugin A resolves against
> the symbols of plugin B. When you now unload plugin B you will get a crash
> the next time you access plugin A.
Isn't this a bug in the DL machinery. Why can't it track the dependency
DAG? (or is unloading specifically undefined in such a case?)

> To what _extent_ does linking without RTLD_GLOBAL break RTTI? Looking at
> PR3993 breakage there seems to happen because the module that does the
> dlopen'ing doesn't strongly define class B (how do you call that, "class B
> isn't being emitted"?)  That situation could be prevented most of the time I
> think. (I believe such classes also have a negative impact on prelinking)
Not saying RTLD_GLOBAL (and linking the main executable with -E), effectively
places each dlopen'd library in its own namespace. RTTI across library
boundaries would not work.

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Jakub Jelinek]

On Sun, Dec 09, 2001 at 11:40:43PM -0800, Waldo Bastian wrote:
> (Unloading plugins is a risky business anyway, because with 2.9x the process 
> will crash on exit when there were static objects declared within 
> function-scope in the plugin.)

This should work, provided you have recent enough glibc (2.2.4) and use
recent enough compiler for both glibc building and to build all relevant shared
libs (CVS 2.95.x with __dso_handle should work, 2.96-RH too, gcc3+
likewise).
If you see any problems, please file a bug report against glibc.

	Jakub

Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Nathan Sidwell]

Waldo Bastian wrote:

> That's pretty bad because loading (dlopen'ing) parts with RTLD_GLOBAL is
> asking for trouble. There is no way that we can guarantee that one part
> doesn't by chance use the same name for some class/symbols as another part,
> since parts may get developed independently of each other.
> 
> We are already running into trouble with the flash plugin colliding with
> OpenGL (both define "DisplayList") and things like this aren't helping the
> situation.
Other than reiterating what Joe Buck said, what you describe sounds
like a job for namespaces. Ok, so you'd have to retrofit them - but
you've got to do something retroactively anyway.  If you cannot do that
then you might be able to do some linker symbol remapping. For instance,
a) all the classes you wish to be dcastable/throwable across shared library
boundaries should be placed in the 'ReallyGlobal' namespace (for want of a
better name :-)
b) when building the shared library prefix any symbol which is not an
export or import to/from the library and not in the ReallyGlobal namespace
with 'PrivateToLibFoo'

That sounds tricky to me, but as Joe pointed out - you've broken the one
definition rule and 'magically' want the compilation system to know which
multiply defined objects are the same and which are different.

Dirk Mueller wrote:
> Point taken for the RTLD_GLOBAL part, but why do we need RTLD_NOW in order
> to make RTTI work, as the original posting pointed out ?
You should be able to do it lazily too.

But, RTLD_GLOBAL doesn't work on (at least) gnu.linux i86 (see gcc bug 4993).
I've not had time to investigate further, but aim to do so shortly.

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org