[parisc-linux] binfmt_som

[parisc-linux] binfmt_som

[Matthew Wilcox]

I plunged further into the binfmt_* files today and have a fair idea what needs to be done next.  One passage is slightly troubling me (page 6-126 of the
runtime arch document),

``exec_dsize
This field specifies the size in bytes of the initialised data (does
not have to be a multiple of 4k).  The actual size of the data section
in the file must be a multiple of 4k and can be padded with zeroes to
make it a multiple of 4k.''

Does this mean in the case where exec_dsize is not a multiple of 4k, it
MUST be padded with zeroes, or merely might be padded with zeroes?  If the
former, I don't need to zero them myself in the loader which would be nice.

Also, where does the bss section start?  Is it immediately after the
initialised data or at the next page boundary after it?

binfmt_som is going to be the cleanest binfmt in the kernel when I'm
finished with it :-)  [and then I'm going to clean up the others.]

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

Re: [parisc-linux] binfmt_som

[Jeffrey A Law]

  In message <19990613035254.D31472@mencheca.ch.genedata.com>you write:
  > ``exec_dsize
  > This field specifies the size in bytes of the initialised data (does
  > not have to be a multiple of 4k).  The actual size of the data section
  > in the file must be a multiple of 4k and can be padded with zeroes to
  > make it a multiple of 4k.''
  > 
  > Does this mean in the case where exec_dsize is not a multiple of 4k, it
  > MUST be padded with zeroes, or merely might be padded with zeroes?  If the
  > former, I don't need to zero them myself in the loader which would be nice.
Strictly reading the size in the file is guaranteed to be a multiple of 4k,
but you can't necessarily depend on the pad being zero filled.

However, HP's linker always zero pads.

  > Also, where does the bss section start?  Is it immediately after the
  > initialised data or at the next page boundary after it?
It beings immediately after the initialized data.  Note that HP's linker will
decrease the size of the bss space by the amount of pad needed to fill out the
data space's size to a multiple of 4k.  This saves a little bit of memory in
the resident image.  Note this is only possible when the pad is zero filled.

To the best of my knowledge this behavior is not documented by HP anywhere.  It
is documented in bfd/som.c, as are many of SOM's wonderful quirks.  Search for
exec_header.

In case you're wondering why BFD has to know about this -- consider strip and
objcopy.  If you muck up an executable with those programs BFD has to be
able to recreate the exec header based on the sections that will exist in the
final output file.

jeff

[parisc-linux] binfmt_som

[Matthew Wilcox]

I've checked in a binfmt_som which I think might work.  However,
it definitely won't work until someone defines put_user() & friends
in include/asm-parisc/uaccess.h.

I also inserted a declaration of start_thread in <asm/processor.h> --
some platforms have it as a macro, some have it as a function, so I
think linking will now fail with that as an undefined symbol.

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

[parisc-linux] binfmt_som

[Matthew Wilcox]

I was a little over-optimistic about releasing a first cut today,
I guess :-)

I've moved `som.h' from include/asm-parisc/ to include/linux/, like elf.h
& a.out.h.  I've also populated it with the structures which I've needed
so far, copied from the document below.  binfmt_som.c is still showing
extreme signs of its ELF heritage and definitely won't compile yet.

I have a question; what is `union name_pt' defined as?  It's referenced
several times in ``32-bit PA-RISC Run-Time Architecture Document
11.0 version 1.0'', page 3-56 for one example.  However, grepping the
document reveals no trace of a definition of this (or `union name_p'
for that matter).

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

Re: [parisc-linux] binfmt_som

[Mark Klein]

At 01:09 AM 5/31/99 +0200, Matthew Wilcox wrote:

>I have a question; what is `union name_pt' defined as?  

union name_pt {
                char        *n_name;
                unsigned int n_strx;
              };

Since the offsets into the string tables are "table relative", this 
is typically used to adjust the pointer in order to have it actually
point to the name referenced:

space.name.n_name = space.name.n_strx + som_header.space_strings_location;

Now space.name.n_name refers to the actual name instead of the index.

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available