Date: Tue, 21 Sep 1999 11:00:02 -0700 (PDT) From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> To: freebsd-doc@freebsd.org Subject: Re: docs/7914: no elf(5) manpage Message-ID: <199909211800.LAA07318@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR docs/7914; it has been noted by GNATS. 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? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909211800.LAA07318>