Re: Size of .comm section not reported by objdump/size

[Ian Lance Taylor]

"Jon Beniston" <address@hidden> writes:

> > > It appears as though objdump does not display information 
> > for data in 
> > > .comm section.
> > 
> > That is correct.  That is because there is no .comm section.  
> > Instead this information is represented by defining a common 
> > symbol.  A common symbol has a name and a size.  The linker 
> > will allocate memory for it when producing a fully linked 
> > executable, or when invoked with the -d option.  A common 
> > symbol may be replaced by a fully defined symbol; look at the 
> > documentation for the --warn-common option.
> 
> Okay, I accept I'm using incorrect terminology. However, would it not be
> useful if objdump -h or size were to display this information somehow?
> For size, it should no doubt be displayed in an additional column, but
> not displaying it at all seems kind of misleading.
> 
> > Common symbols will be displayed by nm or objdump -t.
> 
> Indeed, however, the total memory used for all common symbols isn't
> summarised. 

It would never be correct for objdump -h to display information about
common symbols, because they are not in sections.  objdump -h displays
section headers.

The size handling is due to the historical way that Unix linkers have
treated common symbols.  Unix linkers will merge multiple common
symbols, and choose the larger size.  That means that there is no
reliable way to include common symbols in size output.  Reporting the
sizes of common symbols for several .o files and adding them together
would also give you the wrong information.

That said, I would not be opposed to adding an option to size to
report the total size of common symbols.

Ian