[9front] [PATCH] a.out(6): document dynamically loadable modules

[9front] [PATCH] a.out(6): document dynamically loadable modules

[Humm]

The loaders can generate export tables in executables and build
dynamically loadable modules and there is a library to load those
floating around.  This documents the format of dynamically loadable
modules.
---
I’m sure I’m bad at wording.

---
diff e2a8d3493ab0fdc345b6513a53f30f2b4f36ed97 43b5a35ac0af25c778899143766e1003fb821830
--- a/sys/man/6/a.out	Mon Nov 22 00:42:13 2021
+++ b/sys/man/6/a.out	Sat Nov 27 16:07:35 2021
@@ -4,10 +4,10 @@
 .SH SYNOPSIS
 .B #include <a.out.h>
 .SH DESCRIPTION
-An executable Plan 9 binary file has up to six sections:
-a header, the program text, the data,
-a symbol table, a PC/SP offset table (MC68020 only),
-and finally a PC/line number table.
+An executable Plan 9 binary file has up to seven sections: a header,
+the program text, the data, a symbol table, a PC/SP offset table
+(MC68020 only), a PC/line number table, and finally relocation data
+(dlm only).
 The header, given by a structure in
 .BR <a.out.h> ,
 contains 4-byte integers in big-endian order:
@@ -26,6 +26,7 @@
 } Exec;
 
 #define HDR_MAGIC	0x00008000	/* header expansion */
+#define DYN_MAGIC	0x80000000	/* dynamically loadable module */
 
 #define	_MAGIC(f, b)	((f)|((((4*(b))+0)*(b))+7))
 #define	A_MAGIC	_MAGIC(0, 8)		/* 68020 */
@@ -259,6 +260,48 @@
 first previous
 .B z
 symbol in the symbol table.
+.PP
+In dynamically loadable modules, relocation data follows directly
+after the PC/line number table.
+It starts with the 4-byte big-endian size of the following data, which
+consists of an import table and a relocation table.
+The import table starts with the 4-byte big-endian number of imported
+symbols, followed by a list of entries, laid out as:
+.IP
+.EX
+u32int sig;	/* big-endian */
+char   name[\f2n\fP];	/* NUL-terminated */	
+.EE
+.PP
+.I Sig
+is the type signature value generated by the C compiler's
+.B signof
+operator applied to the type.
+.I Name
+is the linkage name of the function or data.
+.PP
+The relocation table starts with the 4-byte big-endian number of
+fixups, followed by a list of those, each laid out as:
+.IP
+.EX
+uchar m;
+uchar ra[\f2c\fP];
+.EE
+.PP
+The four low bits of
+.I m
+are an architecture-dependent relocation mode.
+.I C
+is 2 raised to the power of the two high bits of
+.IR m ,
+which can be 0, 1, or 2.
+.I Ra
+is a big-endian increment of the working address in the module.
+Each iteration in the process of relocation, the working address is
+incremented by the current
+.IR ra .
+Then, the value in the module at the working address is modified as
+specified by the relocation mode.
 .SH "SEE ALSO"
 .IR db (1), 
 .IR acid (1), 
@@ -273,3 +316,5 @@
 .B -a
 flags on the compilers will produce symbols for
 .IR acid (1).
+.PP
+Dynamically loadable modules exist, and aren't even used anywhere.

Re: [9front] [PATCH] a.out(6): document dynamically loadable modules

[Humm]

ping

Anyone willing to look at this, to commit this, to send nice words, to 
send any reply at all?

-- 
Humm

Re: [9front] [PATCH] a.out(6): document dynamically loadable modules

[Sigrid Solveig Haflínudóttir]

I propose we remove it altogether instead.

Re: [9front] [PATCH] a.out(6): document dynamically loadable modules

[Eli Cohen]

here what the fuck are you doing, fella? we have size constraints,
we're running out of space on the CD ROM. I propose we skip this too.

I still feel we should remove all the binaries from the CD ROM and put
on a brand spanking new 8a, 8c, and 8l.

we need better rpi audio, I'm not sure either of these are any good.
mine is probably easier to fix, but it's still gonna sound like shit.

On Sat, Dec 4, 2021 at 3:40 PM Sigrid Solveig Haflínudóttir
<ftrvxmtrx@gmail.com> wrote:
>
> I propose we remove it altogether instead.

Re: [9front] [PATCH] a.out(6): document dynamically loadable modules

[Eli Cohen]

unless you meant kind words. send me those, too.

On Sat, Dec 4, 2021 at 3:49 PM Eli Cohen <echoline@gmail.com> wrote:
>
> here what the fuck are you doing, fella? we have size constraints,
> we're running out of space on the CD ROM. I propose we skip this too.
>
> I still feel we should remove all the binaries from the CD ROM and put
> on a brand spanking new 8a, 8c, and 8l.
>
> we need better rpi audio, I'm not sure either of these are any good.
> mine is probably easier to fix, but it's still gonna sound like shit.
>
> On Sat, Dec 4, 2021 at 3:40 PM Sigrid Solveig Haflínudóttir
> <ftrvxmtrx@gmail.com> wrote:
> >
> > I propose we remove it altogether instead.

Re: [9front] [PATCH] a.out(6): document dynamically loadable modules

[Eli Cohen]

oh. is this for the quake 2 mission packs? I saw that had already been
handled, it didn't use up many bytes anyway

On Sat, Dec 4, 2021 at 3:49 PM Eli Cohen <echoline@gmail.com> wrote:
>
> unless you meant kind words. send me those, too.
>
> On Sat, Dec 4, 2021 at 3:49 PM Eli Cohen <echoline@gmail.com> wrote:
> >
> > here what the fuck are you doing, fella? we have size constraints,
> > we're running out of space on the CD ROM. I propose we skip this too.
> >
> > I still feel we should remove all the binaries from the CD ROM and put
> > on a brand spanking new 8a, 8c, and 8l.
> >
> > we need better rpi audio, I'm not sure either of these are any good.
> > mine is probably easier to fix, but it's still gonna sound like shit.
> >
> > On Sat, Dec 4, 2021 at 3:40 PM Sigrid Solveig Haflínudóttir
> > <ftrvxmtrx@gmail.com> wrote:
> > >
> > > I propose we remove it altogether instead.

Re: [9front] [PATCH] a.out(6): document dynamically loadable modules

[Kurt H Maier]

On Sat, Dec 04, 2021 at 03:52:15PM -0800, Eli Cohen wrote:
> oh. is this for the quake 2 mission packs? I saw that had already been
> handled, it didn't use up many bytes anyway

stop spamming the mailing list you dirtbag

Re: [9front] [PATCH] a.out(6): document dynamically loadable modules

[Humm]

Quoth Sigrid Solveig Haflínudóttir:
>I propose we remove it altogether instead.

I have no problem with that.  Afaik, that would require deep dives 
only into the compilers and loaders.  Those, I don’t really wanna do.  
The loaders are an unreadable mess to me.  Though, I did look into it 
a little when finding out how all that stuff works and modifying 
libdynld to work on amd64.

If that stuff stays with us for the time being, though, I’m in favor 
of at least having it documented.

-- 
Humm

Re: [9front] [PATCH] a.out(6): document dynamically loadable modules

[Humm]

Quoth Eli Cohen:
>oh. is this for the quake 2 mission packs? I saw that had already been
>handled, it didn't use up many bytes anyway

I have nothing to do with the awesome game ports.

Last time I looked, the Quake II mod stuff was still linked into the 
q2* binaries.  The only uses of dlms I know of are some way for 
Inferno to load drivers dynamically and a little attempt to get lu9 to 
use these.

(Re drivers: It might be somewhat nice to be able to load 9front 
drivers dynamically while developing, but you can always boot kernels 
in vmx (without risking crashing the one you’re running (other than 
vmx doing that itself)).  Not that I ever messed with 9front drivers.)

-- 
Humm

Re: [9front] [PATCH] a.out(6): document dynamically loadable modules

[Steve Simon]

why ont contact charles forsyth who (i believe) wrote the code and i thought he had written manual pages too.

Re: [9front] [PATCH] a.out(6): document dynamically loadable modules

[Humm]

Quoth Steve Simon:
>why ont contact charles forsyth who (i believe) wrote the code and 
>i thought he had written manual pages too.

I don’t know who wrote what code.  There is man page for dynld, which 
also describes export and import tables, and 2l(1) describes -x and 
-u, but I don’t know of any docs about the format of the dynamic load 
section.

-- 
Humm

Re: [9front] [PATCH] a.out(6): document dynamically loadable modules

[ori]

Quoth Humm <hummsmith42@gmail.com>:
> 
> The loaders can generate export tables in executables and build
> dynamically loadable modules and there is a library to load those
> floating around.  This documents the format of dynamically loadable
> modules.

got pinged: looks good, committed.

we can revert this if anyone ever sends a patch
to remove dynamic modules, until then we should
at least document this.