bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tail.c: variable pid not initialized


From: Bob Proulx
Subject: Re: tail.c: variable pid not initialized
Date: Fri, 28 Sep 2007 15:09:28 -0600
User-agent: Mutt/1.5.9i

Andreas Schwab wrote:
> Michael Geng wrote:
> > I don't understand where the static variable pid in tail.c gets 
> > initialized when tail is invoked without --pid option. 
> 
> Variables of static storage duration are always initialized, before
> program startup.

This is the "bss" (Block Started by Symbol) section of the executable
as shown by the 'size' command on executables.  It contains
"uninitialized" global data.

  $ size /usr/bin/tail
   text    data     bss     dec     hex filename
  33025     516     360   33901    846d /usr/bin/tail

In C global variables are initialized to zero by default.  Because no
"immediate data" need be associated with the program the executable
size is optimized by placing this in the bss area.  At program start
all global data not otherwise set to an immediate data value is
initialized to zero.  They effectively take up no space in the on disk
executable that way.

  http://en.wikipedia.org/wiki/Block_Started_by_Symbol

If any value is set for those variables then they are moved into the
data area and the executable image grows to hold the data values
specified.  Therefore images are usually smaller if variables are not
explicitly initialized but left to the default initialization in the
BSS.  This is part of the language and C requires this run-time
initialization.  The system needs to do it anyway for security to keep
programs from seeing leftover data from other processes and so this is
effectively free.  (Otherwise programs could allocate a large chunk of
memory hoping to get lucky trolling through it for nuggets from other
programs.)

Data with values in the data area may be adjusted using debuggers,
such as the old adb, that can write new data there.  The values may be
changed in the on disk executable file image.  It is a feature often
used by the Unix kernel to configure things like udp checksumming on
or off and various other things.  Not often used by application
programs, for good reason.

And the name BSS is interesting too.

  http://www.faqs.org/faqs/unix-faq/faq/part1/

  bss = "Block Started by Symbol"
        
        Dennis Ritchie says:

            Actually the acronym (in the sense we took it up; it may
            have other credible etymologies) is "Block Started by
            Symbol." It was a pseudo-op in FAP (Fortran Assembly
            [-er?]  Program), an assembler for the IBM
            704-709-7090-7094 machines.  It defined its label and set
            aside space for a given number of words.  There was
            another pseudo-op, BES, "Block Ended by Symbol" that did
            the same except that the label was defined by the last
            assigned word + 1.  (On these machines Fortran arrays were
            stored backwards in storage and were 1-origin.)

            The usage is reasonably appropriate, because just as with
            standard Unix loaders, the space assigned didn't have to
            be punched literally into the object deck but was
            represented by a count somewhere.

Bob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]