[9fans] 8c and elf shared libraries

[Steve Simon]

Various projects have worked on 8c to make it generate code for other OSs,
have any of these resulted in code that could generate a very _very_ simple
ELF shared library sutiable for linux?

-Steve

[Ethan Grammatikidis]

On Wed, 11 Jul 2012 17:15:26 +0100

Post by Steve Simon
Various projects have worked on 8c to make it generate code for other OSs,
have any of these resulted in code that could generate a very _very_ simple
ELF shared library sutiable for linux?
-Steve

The 8l in Go can produce ELF binaries -- it's the linker rather than
the compiler you want to look at for this. Last I heard, Go's 8l wasn't
compatible with Plan 9's 8c, but there's an 8c in Go so that doesn't
matter too much. I'm sure some Go fans want to use system C libraries
by dynamic linking, but I'm not so sure about producing a linkable
library.

Thinking it over, I'd rather use the regular Linux toolchain for the
task. You can still write sensible C for gcc to compile, and I think
you'll have a lot less work to do. Besides, it's the approach taken by
p9p, inferno, and drawterm, it works well for them. If you're concerned
about compile time just lower the optimisation level or choose a
generic architecture to optimise for.

[erik quanstrom]

Post by Ethan Grammatikidis
Thinking it over, I'd rather use the regular Linux toolchain for the
task. You can still write sensible C for gcc to compile, and I think

we don't know what the task is.

Post by Ethan Grammatikidis
you'll have a lot less work to do. Besides, it's the approach taken by
p9p, inferno, and drawterm, it works well for them.

invoking the transitive property of the unknown.

- erik

[Ethan Grammatikidis]

On Thu, 12 Jul 2012 01:42:55 -0400

Post by erik quanstrom

Post by Ethan Grammatikidis
Thinking it over, I'd rather use the regular Linux toolchain for the
task. You can still write sensible C for gcc to compile, and I think

we don't know what the task is.

Fair point. I had stared at the email until I thought I knew what it
was about. Bad habit of mine.

Post by erik quanstrom

Post by Ethan Grammatikidis
you'll have a lot less work to do. Besides, it's the approach taken by
p9p, inferno, and drawterm, it works well for them.

invoking the transitive property of the unknown.
- erik

[Christopher Nielsen]

On Wed, Jul 11, 2012 at 9:51 PM, Ethan Grammatikidis

Post by Ethan Grammatikidis
On Wed, 11 Jul 2012 17:15:26 +0100

Post by Steve Simon
Various projects have worked on 8c to make it generate code for other OSs,
have any of these resulted in code that could generate a very _very_ simple
ELF shared library sutiable for linux?
-Steve

The 8l in Go can produce ELF binaries -- it's the linker rather than
the compiler you want to look at for this. Last I heard, Go's 8l wasn't
compatible with Plan 9's 8c, but there's an 8c in Go so that doesn't
matter too much. I'm sure some Go fans want to use system C libraries
by dynamic linking, but I'm not so sure about producing a linkable
library.

Though I cannot find the message now, I recall Russ commenting to
someone that the Go linker is not tooled for C ELF binaries; it is
very Go specific. Having worked on the NetBSD port and had to spelunk
the linker, I believe that to be true. Russ would be the better
authority, though.

The ?c compilers included with Go are derivatives of Inferno's ?c compilers.

[Steve Simon]

Thanks to all who have replied.

I have spoken to russ; 8l may be able to generate object files soon,
but there is no plan for support for shared libraries.

Its OK, I still have some options:

use gcc/gas/gld on linux
generate the shared library as a blind data file on plan9
modify (hack) an existing linux shared library as a data file on plan9

the first seems the obvious choice but I would rather not have to rely on
an existing linux system, and extracting the correct build options
from linux's build structure is... complex.

its not as vile as it sounds the shared library in question is the
linux vdso systemcall interface and its tiny (three entry points from memory),
its just a shame that I have been unable to come up with an clean way of
generating the file on plan9.

-Steve

[Charles Forsyth]

I don't think any of them generate the right addressing to implement a
dynamic library (in the Linux style).
Data is addressed directly, assuming one data per text. Dynamic libraries
need to create a data segment
for each application sharing the library text, so the references to the
data somehow need to be indirect.
There is usually some form of indirect linkage to do that, although I don't
know the details for the Linux/ELF variant.

[erik quanstrom]

i wonder if you could use the gs global register trick
and a bit of runtime setup to implement this.

(ducks)

- erik

[Charles Forsyth]

Normally with these schemes you need to save and restore the module (data)
pointer appropriately for calls in and out of the library.
Each library has its own data. For the library to be used by Linux
applications you'd need to mimic the conventions expected by the Linux
programs closely. The code also needs to be position-independent (in most
of the methods I've seen).

The machines aren't well-suited for the software we now run. We spend quite
a bit of time emulating protected procedures and dynamic linkage.

Post by erik quanstrom
i wonder if you could use the gs global register trick
and a bit of runtime setup to implement this.
(ducks)
- erik

[hiro]

just use cygwin

[steve]

ok, i should explain more.

i want to cate a linux vdso shared library for linuxemu,
this will run exclusively on plan9, and will contain only one
entrypoint, a few bytes of text and no data or bss.

the file must be linux compatible as the linux dynamic linker
must be able to attach my shared library to the linux application
being started (by linuxemu).

i am just trying to avoid shipping a binary with the linuxemu source,
or requiring the end user has a running linux system to bootstrap
linuxemu - however this amy be unavoidable.

-Steve

[Ethan Grammatikidis]

On Wed, 18 Jul 2012 08:02:37 +0100

Post by steve
i am just trying to avoid shipping a binary with the linuxemu source,

Why? I'm thankful you're improving linuxemu but it seems to me you're
giving yourself a headache and delaying your own work for dubious
reasons. A reason for giving source is portability but linux-vdso is
specific to x86. Also this will only need to be compiled on the Plan 9
side of things once, on the very first install.

[Uriel]

On Thu, Jul 12, 2012 at 6:51 AM, Ethan Grammatikidis

Post by Ethan Grammatikidis
On Wed, 11 Jul 2012 17:15:26 +0100

Post by Steve Simon
Various projects have worked on 8c to make it generate code for other OSs,
have any of these resulted in code that could generate a very _very_ simple
ELF shared library sutiable for linux?
-Steve

The 8l in Go can produce ELF binaries -- it's the linker rather than
the compiler you want to look at for this. Last I heard, Go's 8l wasn't
compatible with Plan 9's 8c, but there's an 8c in Go so that doesn't
matter too much. I'm sure some Go fans want to use system C libraries
by dynamic linking, but I'm not so sure about producing a linkable
library.

There has been demand for this in Go-land for a long time, see:
http://code.google.com/p/go/issues/detail?id=256

I'm sure many people, including the core Go team, would be very happy
if somebody worked on this.

Even given my visceral hatred for dynamic linking, this would be quite
useful for things like creating Python modules in Go and other such
tasks.

So please, if you are going to work on this feature for other reasons,
consider doing it via improving the Go toolchain.

Uriel

Post by Ethan Grammatikidis
Thinking it over, I'd rather use the regular Linux toolchain for the
task. You can still write sensible C for gcc to compile, and I think
you'll have a lot less work to do. Besides, it's the approach taken by
p9p, inferno, and drawterm, it works well for them. If you're concerned
about compile time just lower the optimisation level or choose a
generic architecture to optimise for.
--
This is obviously some strange usage of the
word "simple" that I was previously unaware of.