From wosch@panke.de.freebsd.org  Sun Sep 13 02:20:43 1998
Received: from baerenklau.de.freebsd.org (baerenklau.de.freebsd.org [195.185.195.14])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA06369
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 13 Sep 1998 02:20:42 -0700 (PDT)
          (envelope-from wosch@panke.de.freebsd.org)
Received: (from uucp@localhost)
	by baerenklau.de.freebsd.org (8.8.8/8.8.8) with UUCP id LAA00596
	for FreeBSD-gnats-submit@freebsd.org; Sun, 13 Sep 1998 11:20:28 +0200 (CEST)
	(envelope-from wosch@panke.de.freebsd.org)
Received: (from wosch@localhost)
	by campa.panke.de (8.8.8/8.8.8) id LAA00813;
	Sun, 13 Sep 1998 11:04:32 +0200 (MET DST)
	(envelope-from wosch)
Message-Id: <199809130904.LAA00813@campa.panke.de>
Date: Sun, 13 Sep 1998 11:04:32 +0200 (MET DST)
From: Wolfram Schneider <wosch@panke.de.freebsd.org>
Reply-To: wosch@panke.de.freebsd.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: no elf(5) manpage
X-Send-Pr-Version: 3.2

>Number:         7914
>Category:       docs
>Synopsis:       no elf(5) manpage
>Confidential:   no
>Severity:       non-critical
>Priority:       high
>Responsible:    freebsd-doc
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Sep 13 02:30:04 PDT 1998
>Closed-Date:    Sun Oct 31 13:38:19 PST 1999
>Last-Modified:  Sun Oct 31 13:40:46 PST 1999
>Originator:     Wolfram Schneider
>Release:        FreeBSD 2.2.6-STABLE i386
>Organization:
>Environment:

FreeBSD still has no elf(5) manpage, similar to a.out(5).
FreeBSD 3.0 will use elf as default binary format. So we must
have a elf(5) manpage!
>Description:
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:

From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>
To: FreeBSD Gnats <freebsd-gnats-submit@freebsd.org>
Cc: wosch@freebsd.org
Subject: Re: docs/7914: no elf(5) manpage
Date: Sun, 12 Sep 1999 22:33:03 +0200

 With great pleasure I present candidate #1
 It's at http://home.wxs.nl/~asmodai/elf.5
 
 Hopefully it'll make it in time for 3.3.
 
 NOTE: what is currently at that URL does NOT discuss advanced
 relocation and dynamic linking [yet].
 
 I will [probably] add those after some other points on my to-do.
 
 Also, I think some of the paragraphs wil be rewritten as my
 understanding of the binary format grows as well as by guidance
 from John D. Polstra (whom I thank for answering my questions).
 
 Feedback much appreciated!
 
 -- 
 Jeroen Ruigrok van der Werven/Asmodai                  asmodai(at)wxs.nl
 The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
 Network/Security Specialist        BSD: Technical excellence at its best
 How are the mighty fallen!
 

From: Nick Sanders <fishy@hotbot.com>
To: freebsd-gnats-submit@freebsd.org, wosch@panke.de.freebsd.org
Cc:  
Subject: Re: docs/7914: no elf(5) manpage
Date: Mon, 20 Sep 1999 17:24:11 -0700

 Greetings.
 
 The manual page itself looks pretty good.  Though I can't verify its
 technical accuracy, I did find a few grammar things and typos.
 
 Please excuse any strange formatting that may occur in this email, since
 this is the first time that I've done this.
 
 #1
 The fields have the following meanings:
 e_ident      
 This array of bytes specify how to interpret the file,
 
 I believe that "specify" should be "specifies".
 
 
 #2
 e_ident      
 This array of bytes specify how to interpret the file, contents.  Within
 this array everything is named by macros, which start with the prefix
 EI_ and may contain values which start with the prefix ELF. The
 following macros are defined:
 
 Once again, should "specify" be "specifies"?  An array specifies, bytes
 specify.
 
 
 #3
 SHN_COMMON     
 Symbols defines relative to this section are common symbols, such as
 Fortran COMMON or unallocated C external variables.
 
 Should "Symbols" be singular?
 
 
 #4
 The main difference between the 32-bit and the 64-but program header
 lies  only in the location of a p_flags member in the total struct. 
 
 Should "64-but" be 64-bit?
 
 
 #5
 PT_INTERP   
 The array element specifies the location and size of a null-terminated
 path name to invoke as an interpreter. This segment type is meaningful
 only for executable files (though it may occur for shared objects).
 However it may present it must precede any loadable segment
 
 The last sentence in this does not make any sense to me.
 
 
 #6
 .data      
 This section holds initialised data that contribute to the program's
 memory image. This section is of type SHT_PROGBITS.  The attribute types
 are SHF_ALLOC and SHF_WRITE.  
 
 Initialised should be "initialized".
 
 
 #7
 .data1     
 This section holds initialised data that contribute to the program's
 memory image. This section is of type SHT_PROGBITS.  The attribute types
 are SHF_ALLOC and SHF_WRITE. 
 
 Initialised should be "initialized".
 
 
 #8
 .init      
 This section holds executable instructions that contribute to the
 process initialisation code.  When a program starts to run the system
 arranges to execute the code in this section before calling the main
 program entry point.  This section is of type SHT_PROGBITS. This section
 holds executable instructions that contribute to the process
 initialisation code. When a program starts to run the system arranges to
 execute the code in this section before calling the main program entry
 point.  This  section is of type SHT_PROGBITS. The attributes used are
 SHF_ALLOC and SHF_EXECINSTR.    
 
 Initialisation should be "initialization" in both occurrences.  Is
 Initialize with an "s" a British spelling?
 
 
 #9
 .relNAME   
 This section holds relocation information as described below.  If the
 file has a loadable segment that includes relocation, the section's
 attributes will include the SHF_ALLOC bit. Otherwise the bit will be
 off. By convention, ``NAME'' is supplied by the section to which the
 relocations apply. Thus a relocation section for .text normally would
 have the name
 
 .rel.text. This section is of type SHT_REL. 
 
 Not sure if this is an error in the file or just my system acting
 funny.  I had an blank rule between "name" and ".rel.text"
 
 
 #10
 STB_WEAK    Weak symbols resemble global symbols, but their
 STB_LOPROC  This value up to and including STB_HIPROC are reserved for
 processor-specific semantics.   
 
 Once again this may just be an error on my machine, but the STB_WEAK
 sentence cuts off as shown above.  
 
 
 
 That is all I found this time through.
 
 - Nick Sanders
 

From: Nick Sanders <fishy@netgate.net>
To: freebsd-gnats-submit@freebsd.org, wosch@panke.de.freebsd.org
Cc:  
Subject: Re: docs/7914: no elf(5) manpage
Date: Mon, 20 Sep 1999 21:27:06 -0700

 This is a multi-part message in MIME format.
 --------------FC2860753AEBAEE799FF5CE7
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 
 I went through the man page again (the source this time, instead of a
 rendered version), and found that a few of my points (#5 and #10) were
 actually the result of my terminal settings being set wrong (thus some
 text was cut off).  
 
 I attached a diff of the changes that I've made to this email.  The only
 issue I didn't know how to fix was #9.  
 
 - Nick
 
 622F 07DD 2F14 86DB B4D1  B807 AACC D086 623A 67F6
 --------------FC2860753AEBAEE799FF5CE7
 Content-Type: text/plain; charset=us-ascii;
  name="elf.5.diff"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline;
  filename="elf.5.diff"
 
 132c132
 < This array of bytes specify how to interpret the file,
 ---
 > This array of bytes specifies how to interpret the file,
 327c327
 < Symbols defines relative to this section are common symbols, such as Fortran
 ---
 > Symbol defines relative to this section are common symbols, such as Fortran
 383c383
 < The main difference between the 32-bit and the 64-but program header lies
 ---
 > The main difference between the 32-bit and the 64-bit program header lies
 731c731
 < This section holds uninitialised data that contributes to the program's
 ---
 > This section holds uninitialized data that contributes to the program's
 744c744
 < This section holds initialised data that contribute to the program's
 ---
 > This section holds initialized data that contribute to the program's
 805c805
 < initialisation code. When a program starts to run the system arranges to
 ---
 > initialization code. When a program starts to run the system arranges to
 
 --------------FC2860753AEBAEE799FF5CE7--
 
 

From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>
To: Nick Sanders <fishy@netgate.net>
Cc: freebsd-doc@freebsd.org,
	FreeBSD Gnats <freebsd-gnats-submit@freebsd.org>
Subject: Re: docs/7914: no elf(5) manpage
Date: Tue, 21 Sep 1999 19:51:46 +0200

 [snip diff]
 
 Thanks for the diff.
 
 Everything that needed to be fixed has been fixed, and everything else
 has been left the same =)
 
 Kind regards,
 
 -- 
 Jeroen Ruigrok van der Werven/Asmodai                  asmodai(at)wxs.nl
 The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
 Network/Security Specialist        BSD: Technical excellence at its best
 Hypocrisy is the homage which vice pays to virtue.
 

From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>
To: Nick Sanders <fishy@hotbot.com>
Cc: freebsd-doc@freebsd.org,
	FreeBSD Gnats <freebsd-gnats-submit@freebsd.org>
Subject: Re: docs/7914: no elf(5) manpage
Date: Tue, 21 Sep 1999 19:50:11 +0200

 * Nick Sanders (fishy@hotbot.com) [990921 03:54]:
 >
 > #1
 > The fields have the following meanings:
 > e_ident      
 > This array of bytes specify how to interpret the file,
 > 
 > #2
 > e_ident      
 > This array of bytes specify how to interpret the file, contents.  Within
 > 
 > Once again, should "specify" be "specifies"?  An array specifies, bytes
 > specify.
 
 Corrected #1, #2 is a duplicate of #1.
 
 > #3
 > SHN_COMMON     
 > Symbols defines relative to this section are common symbols, such as
 > Fortran COMMON or unallocated C external variables.
 > 
 > Should "Symbols" be singular?
 
 No, Symbols defined is the correct wording, 't was a mere typo.
 
 > #4
 > The main difference between the 32-bit and the 64-but program header
 > lies  only in the location of a p_flags member in the total struct. 
 > 
 > Should "64-but" be 64-bit?
 
 Another misplacement of the finger.
 
 > #5
 > PT_INTERP   
 > The array element specifies the location and size of a null-terminated
 > path name to invoke as an interpreter. This segment type is meaningful
 > only for executable files (though it may occur for shared objects).
 > However it may present it must precede any loadable segment
 > 
 > The last sentence in this does not make any sense to me.
 
 This must clearly be an error on your machine. I think your follow-up
 mail deals with this.
 
 My test here is:
 
 .It Dv PT_INTERP
 The array element specifies the location and size of a null-terminated
 path name to invoke as an interpreter. This segment type is meaningful
 only for executable files (though it may occur for shared objects). However
 it may not occur more than once in a file. If it is present it must precede
 any loadable segment entry.
 
 > #6
 > .data      
 > This section holds initialised data that contribute to the program's
 > memory image. This section is of type SHT_PROGBITS.  The attribute types
 > are SHF_ALLOC and SHF_WRITE.  
 > 
 > Initialised should be "initialized".
 
 If you are a United States citizen. I prefer the Queen's [Original/Olde]
 English myself.
 
 > #7
 > .data1     
 > This section holds initialised data that contribute to the program's
 > memory image. This section is of type SHT_PROGBITS.  The attribute types
 > are SHF_ALLOC and SHF_WRITE. 
 > 
 > Initialised should be "initialized".
 
 See #6.
 
 > #8
 > .init      
 >
 > Initialisation should be "initialization" in both occurrences.  Is
 > Initialize with an "s" a British spelling?
 
 Bingo =)
 
 See $6.
 
 > #9
 > .relNAME   
 > This section holds relocation information as described below.  If the
 > file has a loadable segment that includes relocation, the section's
 > attributes will include the SHF_ALLOC bit. Otherwise the bit will be
 > off. By convention, ``NAME'' is supplied by the section to which the
 > relocations apply. Thus a relocation section for .text normally would
 > have the name
 > 
 > .rel.text. This section is of type SHT_REL. 
 > 
 > Not sure if this is an error in the file or just my system acting
 > funny.  I had an blank rule between "name" and ".rel.text"
 
 I have nothing in my mdoc source file which should generate the extra
 blank line; however nroff -man elf.5 has been known to create spurious
 blank lines [or any other *roff for that matter].
 
 > #10
 > STB_WEAK    Weak symbols resemble global symbols, but their
 > STB_LOPROC  This value up to and including STB_HIPROC are reserved for
 > processor-specific semantics.   
 > 
 > Once again this may just be an error on my machine, but the STB_WEAK
 > sentence cuts off as shown above.  
 
 This is really a problem on your machine:
 
 .It Dv STB_WEAK
 Weak symbols resemble global symbols, but their definitions have lower
 precedence.
 
 That's what I have.
 
 Anyways, the things you did find are fixed and I am greatful for that.
 
 Cheers,
 
 -- 
 Jeroen Ruigrok van der Werven/Asmodai                  asmodai(at)wxs.nl
 The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
 Network/Security Specialist        BSD: Technical excellence at its best
 What is history but a fable agreed 'pon?
 

From: Nik Clayton <nik@freebsd.org>
To: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>
Cc: Nick Sanders <fishy@hotbot.com>, freebsd-doc@freebsd.org,
	FreeBSD Gnats <freebsd-gnats-submit@freebsd.org>
Subject: Re: docs/7914: no elf(5) manpage
Date: Wed, 22 Sep 1999 00:29:55 +0100

 On Tue, Sep 21, 1999 at 07:50:11PM +0200, Jeroen Ruigrok/Asmodai wrote:
 > * Nick Sanders (fishy@hotbot.com) [990921 03:54]:
 > > .data      
 > > This section holds initialised data that contribute to the program's
 > > memory image. This section is of type SHT_PROGBITS.  The attribute types
 > > are SHF_ALLOC and SHF_WRITE.  
 > > 
 > > Initialised should be "initialized".
 > 
 > If you are a United States citizen. I prefer the Queen's [Original/Olde]
 > English myself.
 
 FWIW, I think we can safely assume that the default English variant is
 US English.  There was a sweep through the man pages about a year or
 so ago, correcting things like this and converting them to the US format.
 
 At some point we may put together a doc/en_GB.ISO_8859-1/ directory 
 hierarchy, but I have a few other things on my plate first. . .
 
 N
 -- 
  [intentional self-reference] can be easily accommodated using a blessed,
  non-self-referential dummy head-node whose own object destructor severs
  the links.
     -- Tom Christiansen in <375143b5@cs.colorado.edu>
 

From: Mark Ovens <mark@ukug.uk.freebsd.org>
To: Nik Clayton <nik@freebsd.org>
Cc: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>,
	Nick Sanders <fishy@hotbot.com>, freebsd-doc@freebsd.org,
	FreeBSD Gnats <freebsd-gnats-submit@freebsd.org>
Subject: Re: docs/7914: no elf(5) manpage
Date: Wed, 22 Sep 1999 18:17:29 +0100

 On Wed, Sep 22, 1999 at 12:29:55AM +0100, Nik Clayton wrote:
 > On Tue, Sep 21, 1999 at 07:50:11PM +0200, Jeroen Ruigrok/Asmodai wrote:
 > > * Nick Sanders (fishy@hotbot.com) [990921 03:54]:
 > > > .data      
 > > > This section holds initialised data that contribute to the program's
 > > > memory image. This section is of type SHT_PROGBITS.  The attribute types
 > > > are SHF_ALLOC and SHF_WRITE.  
 > > > 
 > > > Initialised should be "initialized".
 > > 
 > > If you are a United States citizen. I prefer the Queen's [Original/Olde]
 > > English myself.
 > 
 > FWIW, I think we can safely assume that the default English variant is
 > US English.  There was a sweep through the man pages about a year or
 > so ago, correcting things like this and converting them to the US format.
 > 
 
 Ah, my favourite spelling debate:) If you consult the OED you will
 find that such words really end in ~ize. In the latest versions
 they also include ~ise, but only as an *alternative* spelling. I
 suspect that it is because Americans use ~ize that most people
 assume that we, in the UK, should use ~ise and because of this
 widespread (mis)spelling it is now included in the OED.
 
 To quote the manpage for the ``-b'' (British) option to spell(1)
 on Suns:
 
 
      -b          Check  British  spelling.   Besides   preferring
                  "centre",  "colour",  "programme", "speciality",
                  "travelled", and so on, this option insists upon
                  -ise  in  words  like  standardize, despite what
                  Fowler and the OED say.
 
 So I vote for "Initialize" (but also for "colour", "favour" etc ;-) )
 
 > At some point we may put together a doc/en_GB.ISO_8859-1/ directory 
 > hierarchy, but I have a few other things on my plate first. . .
 > 
 > N
 > -- 
 >  [intentional self-reference] can be easily accommodated using a blessed,
 >  non-self-referential dummy head-node whose own object destructor severs
 >  the links.
 >     -- Tom Christiansen in <375143b5@cs.colorado.edu>
 > 
 > 
 > To Unsubscribe: send mail to majordomo@FreeBSD.org
 > with "unsubscribe freebsd-doc" in the body of the message
 
 -- 
 STATE-OF-THE-ART: Any computer you can't afford.
 OBSOLETE: Any computer you own.
 ________________________________________________________________
       FreeBSD - The Power To Serve http://www.freebsd.org
       My Webpage http://ukug.uk.freebsd.org/~mark/
 mailto:mark@ukug.uk.freebsd.org              http://www.radan.com
 
 
State-Changed-From-To: open->closed 
State-Changed-By: phantom 
State-Changed-When: Sun Oct 31 13:38:19 PST 1999 
State-Changed-Why:  
elf.5 manual page  is present now in main source tree. 
>Unformatted:
