Re: [9fans] Format for relocatable objects

Re: [9fans] Format for relocatable objects

[lucio]

> one nice thing about the scheme is that in the compiler suite
> only the loader knows or needs to know
> the bit patterns and peculiar properties of the actual machine.

Thank you for reminding me, I thought I'd seen the details somewhere.
Now to actually absorb them, given that if I were to read your
comments literally, I'd assume that the intermediate code would be
machine independent.  Seeing that such is not the case, I'd better
look a little deeper.

It would be a shame (but no disaster) if Binutil's "nm" and other
tools could not at least display native Plan 9 intermediate files.  I
need to know or decide how far to take this exercise.

++L

Re: [9fans] Format for relocatable objects

[erik quanstrom]

> It would be a shame (but no disaster) if Binutil's "nm" and other
> tools could not at least display native Plan 9 intermediate files.  I
> need to know or decide how far to take this exercise.

why would that be advantagous on plan 9?  if you teach
gcc to output, e.g., 8.out, then what is gained by having
gnu binutils version of nm?

- erik

Re: [9fans] Format for relocatable objects

[Charles Forsyth]

>Now to actually absorb them, given that if I were to read your
>comments literally, I'd assume that the intermediate code would be
>machine independent.

not if you're reading my comments literally. i'd already observed
that "they contain target-dependent code but not precise machine instructions",
before saying "only the loader knows or needs to know the bit patterns
and peculiar properties of the actual machine".  given that it's target-dependent
it certainly isn't machine independent.  it's target-dependent because
register allocation has been done with regard to the target register set, and because
the compiler has generated code that refers to instructions (including
virtual instructions) available on that target (eg, AMULHW or AMULHWCC
on the powerpc, but not on the x86).

the set of instructions used by the compiler for a given
target is represented by a set of enumeration values in 5.out.h, q.out.h, etc.
the compiler and assembler cannot use anything outside that set. the instructions are represented
in the .[8kvq5...] files by those enumeration values; that includes virtual
instructions and pseudo-ops such as ANAME, ASIGNAME, ATEXT, and AGLOBL.
the enum values are written as one or two-byte value, followed by operand descriptors.
the operands to instructions resemble those on the target, so that they can use
double-indexing if the machine supports that, or shift/rotate (cf. ARM).
they are virtual to the extent that some irregularities of the actual processor
are glossed over, and also because external references are by name, not by address.
the representation is therefore an abstraction of the real machine,
but it isn't machine independent. different machines have different types and numbers
of operands, and different representations in detail for them.

libmach has modules 5obj.c kobj.c etc. that interpret the formats for the benefit
of nm and ar amongst others.

Re: [9fans] Format for relocatable objects

[Roman V. Shaposhnik]

On Tue, 2009-01-06 at 15:09 -0500, erik quanstrom wrote:
> > It would be a shame (but no disaster) if Binutil's "nm" and other
> > tools could not at least display native Plan 9 intermediate files.  I
> > need to know or decide how far to take this exercise.
>
> why would that be advantagous on plan 9?  if you teach
> gcc to output, e.g., 8.out, then what is gained by having
> gnu binutils version of nm?

Not *on* Plan9, but *for* Plan9: think cross-environment.

Thanks,
Roman.

Re: [9fans] Format for relocatable objects

[erik quanstrom]

> On Tue, 2009-01-06 at 15:09 -0500, erik quanstrom wrote:
>> > It would be a shame (but no disaster) if Binutil's "nm" and other
>> > tools could not at least display native Plan 9 intermediate files.  I
>> > need to know or decide how far to take this exercise.
>>
>> why would that be advantagous on plan 9?  if you teach
>> gcc to output, e.g., 8.out, then what is gained by having
>> gnu binutils version of nm?
>
> Not *on* Plan9, but *for* Plan9: think cross-environment.

let's just assume that everyone here knows where to find linux.

- erik

Re: [9fans] Format for relocatable objects

[Roman V. Shaposhnik]

On Tue, 2009-01-06 at 17:54 -0500, erik quanstrom wrote:
> > On Tue, 2009-01-06 at 15:09 -0500, erik quanstrom wrote:
> >> > It would be a shame (but no disaster) if Binutil's "nm" and other
> >> > tools could not at least display native Plan 9 intermediate files.  I
> >> > need to know or decide how far to take this exercise.
> >>
> >> why would that be advantagous on plan 9?  if you teach
> >> gcc to output, e.g., 8.out, then what is gained by having
> >> gnu binutils version of nm?
> >
> > Not *on* Plan9, but *for* Plan9: think cross-environment.
>
> let's just assume that everyone here knows where to find linux.

Well, that's what I meant: binutils on Linux (or any other UNIX
for that matter) understood Plan9's *.out files you can set up
a cross-environment *on Linux* and deploy on Plan9. I'm not sure
its a killer application, but its a use case.

Thanks,
Roman.

Re: [9fans] Format for relocatable objects

[lucio]

> Not *on* Plan9, but *for* Plan9: think cross-environment.

I thought about that, but dismissed it because Plan 9 objects exist
only in a Plan 9 environment in the scenario Erik envisages.  But,
funny enough, I am currently using NetBSD as my GCC platform, so your
point is not entirely irrelevant.

++L

Re: [9fans] Format for relocatable objects

[lucio]

> Well, that's what I meant: binutils on Linux (or any other UNIX
> for that matter) understood Plan9's *.out files you can set up
> a cross-environment *on Linux* and deploy on Plan9. I'm not sure
> its a killer application, but its a use case.

It's also a necessity in order to bootstrap the GCC compiler, although
you need it only once.  The other option is to go back into
pre-history and compile a very old version of GCC under KenCC, but
then the number of iterations may be much greater.

You don't need the Binutils for anything other than executables, but I
was hoping to get them for free or at least at a very low price, it
seems that is not the case.

++L

PS: I may still go as far back as that, because GCC 2.95 (my memory
may be faulty there) was a benchmark compiler (just before the EGCS
fad) and may be worth keeping around as a reference.

Re: [9fans] Format for relocatable objects

[Charles Forsyth]

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

.[8kvq965] ... files are unrelated to a.out.

as ken thompson's paper says
	The object files are binary forms of assembly language,
	similar to what might be passed between
	the first and second passes of an assembler.
they  contain target-dependent code but not precise machine instructions
(the loader makes the final choice of machine instructions).

one nice thing about the scheme is that in the compiler suite
only the loader knows or needs to know
the bit patterns and peculiar properties of the actual machine.

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

From: lucio@proxima.alt.za
To: 9fans@9fans.net
Subject: [9fans] Format for relocatable objects
Date: Tue, 6 Jan 2009 20:47:06 +0200
Message-ID: <f9a3ba290cd70e70c7dbfe2e161edba8@proxima.alt.za>

Where should I look for the format of Plan 9 objects as created by the
compiler(s) and ready for linking?  I'm hoping there is a place other
than the compiler sources that documents this intermediate format,
which I presume is not totally unlike a.out.

Also, while I'm asking, there must be more than a hint of ELF in the
Linux emulation code, can someone point me to the details?  ELF is low
on my list of favourites, but there may be some useful shortcuts in
giving it a bit of recognition under Plan 9.

++L

PS: in case the context isn't obvious, GNU CC and C++ for Plan 9 are
the eventual objectives, I'm taking a slightly circular approach in an
attempt to understand David Hogan's work a lot better than I do now.

[9fans] Format for relocatable objects

[lucio]

Where should I look for the format of Plan 9 objects as created by the
compiler(s) and ready for linking?  I'm hoping there is a place other
than the compiler sources that documents this intermediate format,
which I presume is not totally unlike a.out.

Also, while I'm asking, there must be more than a hint of ELF in the
Linux emulation code, can someone point me to the details?  ELF is low
on my list of favourites, but there may be some useful shortcuts in
giving it a bit of recognition under Plan 9.

++L

PS: in case the context isn't obvious, GNU CC and C++ for Plan 9 are
the eventual objectives, I'm taking a slightly circular approach in an
attempt to understand David Hogan's work a lot better than I do now.