Re: [9fans] dhog the corruptor!

Re: [9fans] dhog the corruptor!

[David Gordon Hogan]

> This is just for kernel drivers, right?

No, it's a general purpose mechanism.  It's currently only used
for kernel device drivers, but I have my eyes on certain user
mode applications that could benefit.

> While plan9's non-support of dynamic
> linking for arbitrary C programs works just fine, it doesn't seem to work so
> well for languages that only load libraries at run time, such as python or
> perl (or limbo?).

I don't care about python or perl (so shoot me!).  But my experiences
with limbo have taught me that loadable modules can be a powerful
tool.  Limbo also has type signatures, which I have no plans to add
at this stage.

> If the linker can write relocation information, would that
> make it easier to write a dlopen()-like function?

We're not trying to load actual libraries here, but rather modules
of executable code.  Said modules will have a single entry point
(which can be a struct, as it is for device drivers).

Re: [9fans] dhog the corruptor!

[Quinn Dunkan]

> I don't care about python or perl (so shoot me!).  But my experiences
> with limbo have taught me that loadable modules can be a powerful
> tool.  Limbo also has type signatures, which I have no plans to add
> at this stage.

Yeah, trying to maintain static signatures is a whole other kettle of wax.  I
was thinking of dynamically typed languages, though.

> > If the linker can write relocation information, would that
> > make it easier to write a dlopen()-like function?
>
> We're not trying to load actual libraries here, but rather modules
> of executable code.  Said modules will have a single entry point
> (which can be a struct, as it is for device drivers).

That'll work well enough for me.  Single entry point could be a struct of
generic object pointers or a function that installs names in a namespace.

Cool!

forsyth:
> type checking is often ignored in these interfaces.
> with static linking #include and mk are often adequate if
> not perfect, but dynamic linking increases the chances for
> error.

AFAICT, though, dynamically typed languages don't have to worry about it.
Skeptics would say "that's because the chances for error are already at
maximum and can't be increased" :)

Re: [9fans] dhog the corruptor!

[Lucio De Re]

On Tue, Nov 13, 2001 at 04:34:24PM -0800, Quinn Dunkan wrote:
>
> forsyth:
> > type checking is often ignored in these interfaces.
> > with static linking #include and mk are often adequate if
> > not perfect, but dynamic linking increases the chances for
> > error.
>
> AFAICT, though, dynamically typed languages don't have to worry about it.
> Skeptics would say "that's because the chances for error are already at
> maximum and can't be increased" :)

Got bit by that yesterday: my NetBSD packaged "psql" had forgotten to
include -ltermcap on the ld command.  Took me hours to realise it
wasn't an upgrade problem, just finger trouble :-(

No compile time diagnostics, of course.

++L

Re: [9fans] dhog the corruptor!

[Boyd Roberts]

Quinn Dunkan wrote:
> That'll work well enough for me.  Single entry point could be a struct of
> generic object pointers or a function that installs names in a namespace.
>
> Cool!

I had a sneaking suspicion that this stuff fell out of Limbo
and that brucee was behind it.  brucee will have done it right.

brucee has considerable compiler and Ingot experience.

Re: [9fans] dhog the corruptor!

[Boyd Roberts]

forsyth@vitanuova.com wrote:
> it's less of a problem for device drivers because they have a
> narrow interface that doesn't change too often.  it does change, though:
> ulong one year, vlong the next.

I don't see it as a problem.  Remember cyntax(1)?  brucee again.

Re: [9fans] dhog the corruptor!

[forsyth]

>
> AFAICT, though, dynamically typed languages don't have to worry about it.
> Skeptics would say "that's because the chances for error are already at
> maximum and can't be increased" :)

no, they do have to worry about it; it's just that sometimes they
pretend they don't!   it's one reason our dynamically loadable C
modules aren't in the standard Inferno distribution: i'm not happy
about the absence of type checking across the module to kernel interface.
(the interface the module presents to Limbo code that uses it is checked,
of course, but not its own interface to the kernel.)
it's less of a problem for device drivers because they have a
narrow interface that doesn't change too often.  it does change, though:
ulong one year, vlong the next.

Re: [9fans] dhog the corruptor!

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 182 bytes --]

type checking is often ignored in these interfaces.
with static linking #include and mk are often adequate if
not perfect, but dynamic linking increases the chances for
error.


[-- Attachment #2: Type: message/rfc822, Size: 2385 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] dhog the corruptor!
Date: Tue, 13 Nov 2001 15:28:37 -0800
Message-ID: <20011113232842.C7CAC9C404@barf.ugcs.caltech.edu>


> Brucee's implementation just patches the call to point to the
> correct destination.  You don't have to walk any machine code.
> The (modified) linker emits a known call instruction, and relocation
> information which says where it is and what symbol to patch
> it with.  Symbol lookup is done in a highly controlled way.

This is just for kernel drivers, right?  While plan9's non-support of dynamic
linking for arbitrary C programs works just fine, it doesn't seem to work so
well for languages that only load libraries at run time, such as python or
perl (or limbo?).  If the linker can write relocation information, would that
make it easier to write a dlopen()-like function?

Re: [9fans] dhog the corruptor!

[David Gordon Hogan]

[-- Attachment #1: Type: text/plain, Size: 114 bytes --]

It's not quite the same.  No ``thunks'' here.  All the references
are resolved at load time with this schema.


[-- Attachment #2: Type: message/rfc822, Size: 2215 bytes --]

From: "Chris Hollis-Locke" <chris@cjl1.demon.co.uk>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] dhog the corruptor!
Date: Tue, 13 Nov 2001 23:38:46 -0000
Message-ID: <008701c16c9c$57155b80$2248dec2@falken>

> Brucee's implementation just patches the call to point to the
> correct destination.  You don't have to walk any machine code.

MS VXDs work in a similar way - they call it something like
'snap' linkage.  The 'unlinked' call is to a lookup function that
patches the caller (determined by return addr on the stack) to
the actual entry point.  The downside is that you cannot easily
unload or replace a driver that is linked in such a way, which
explains why there are so many "You must now reboot your computer"
messages.
The new WDM may do things differently, I haven't looked at that yet.

Re: [9fans] dhog the corruptor!

[Chris Hollis-Locke]

> Brucee's implementation just patches the call to point to the
> correct destination.  You don't have to walk any machine code.

MS VXDs work in a similar way - they call it something like
'snap' linkage.  The 'unlinked' call is to a lookup function that
patches the caller (determined by return addr on the stack) to
the actual entry point.  The downside is that you cannot easily
unload or replace a driver that is linked in such a way, which
explains why there are so many "You must now reboot your computer"
messages.
The new WDM may do things differently, I haven't looked at that yet.

Re: [9fans] dhog the corruptor!

[Quinn Dunkan]

> Brucee's implementation just patches the call to point to the
> correct destination.  You don't have to walk any machine code.
> The (modified) linker emits a known call instruction, and relocation
> information which says where it is and what symbol to patch
> it with.  Symbol lookup is done in a highly controlled way.

This is just for kernel drivers, right?  While plan9's non-support of dynamic
linking for arbitrary C programs works just fine, it doesn't seem to work so
well for languages that only load libraries at run time, such as python or
perl (or limbo?).  If the linker can write relocation information, would that
make it easier to write a dlopen()-like function?

Re: [9fans] dhog the corruptor!

[David Gordon Hogan]

[-- Attachment #1: Type: text/plain, Size: 321 bytes --]

Brucee's implementation just patches the call to point to the
correct destination.  You don't have to walk any machine code.
The (modified) linker emits a known call instruction, and relocation
information which says where it is and what symbol to patch
it with.  Symbol lookup is done in a highly controlled way.


[-- Attachment #2: Type: message/rfc822, Size: 2504 bytes --]

From: George Michaelson <ggm@apnic.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] dhog the corruptor!
Date: Wed, 14 Nov 2001 08:59:29 +1000
Message-ID: <24453.1005692369@apnic.net>


One thing I've often wondered about is why dynamic linking methods leave
the indirect call around. I discussed this with a smarter person and he
seemed to think the cost of walking the machinecode to find out the base
call, and write in the binary the direct references was too high.

But surely for inner-loop code, or critical frequent call code, it would
be worth avoiding call(indirect-lookup(real-function-name(args...))) all
the time?

So would a plan9 with dynamic linkage live with stacks of indirection or
does it straight-path to the real code?

cheers
	-George
--
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net

Re: [9fans] dhog the corruptor!

[George Michaelson]

One thing I've often wondered about is why dynamic linking methods leave
the indirect call around. I discussed this with a smarter person and he
seemed to think the cost of walking the machinecode to find out the base
call, and write in the binary the direct references was too high.

But surely for inner-loop code, or critical frequent call code, it would
be worth avoiding call(indirect-lookup(real-function-name(args...))) all
the time?

So would a plan9 with dynamic linkage live with stacks of indirection or
does it straight-path to the real code?

cheers
	-George
--
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net

Re: [9fans] dhog the corruptor!

[anothy]

ah. well, then maybe it's a
country of origin thing? ☺

incidently, why on earth did
☺, ☻, and ☹ make it into
unicode? they're fun and all,
but please...
ア

Re: [9fans] dhog the corruptor!

[David Gordon Hogan]

[-- Attachment #1: Type: text/plain, Size: 121 bytes --]

Brucee did the implementation of dynamically loaded
drivers.  I'm just tidying up a bit and making it more
generic.


[-- Attachment #2: Type: message/rfc822, Size: 1600 bytes --]

From: anothy@cosym.net
To: 9fans@cse.psu.edu
Subject: [9fans] dhog the corruptor!
Date: Tue, 13 Nov 2001 17:09:21 -0500
Message-ID: <20011113220935.D03D4199E4@mail.cse.psu.edu>

// Dhog is putting in dynamicly linked drivers...

waitaminute... the same guy's "giving" plan 9 gcc
_and_ dynamicly linked drivers? whoa. aside from
the amount of potentially painful work each
involves, i find it interesting that these two largish
departures from "old-school" plan 9 come from
the same place.

i'm (mostly) kidding. i'm still torn on gcc, but i
like dynamic drivers, at least in theory. getting the
implementation right's another thing...
ア

[9fans] dhog the corruptor!

[anothy]

// Dhog is putting in dynamicly linked drivers...

waitaminute... the same guy's "giving" plan 9 gcc
_and_ dynamicly linked drivers? whoa. aside from
the amount of potentially painful work each
involves, i find it interesting that these two largish
departures from "old-school" plan 9 come from
the same place.

i'm (mostly) kidding. i'm still torn on gcc, but i
like dynamic drivers, at least in theory. getting the
implementation right's another thing...
ア