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 ; 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 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 To: FreeBSD Gnats 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 Network/Security Specialist BSD: Technical excellence at its best How are the mighty fallen! From: Nick Sanders 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 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 To: Nick Sanders Cc: freebsd-doc@freebsd.org, FreeBSD Gnats 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 Network/Security Specialist BSD: Technical excellence at its best Hypocrisy is the homage which vice pays to virtue. From: Jeroen Ruigrok/Asmodai To: Nick Sanders Cc: freebsd-doc@freebsd.org, FreeBSD Gnats 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 Network/Security Specialist BSD: Technical excellence at its best What is history but a fable agreed 'pon? From: Nik Clayton To: Jeroen Ruigrok/Asmodai Cc: Nick Sanders , freebsd-doc@freebsd.org, FreeBSD Gnats 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 To: Nik Clayton Cc: Jeroen Ruigrok/Asmodai , Nick Sanders , freebsd-doc@freebsd.org, FreeBSD Gnats 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: