Re: ELF octets_per_byte

["Maciej W. Rozycki" <macro at linux-mips dot org>]

Dan,

> >  As to the symbol size I think it needs to be set to whatever the 
> > C-language's `sizeof' operator would return for a unit of storage of the 
> > same size.
> 
> As I mentioned earlier this evening, the Zip CPU features:
> 
> sizeof(char)=sizeof(short)=sizeof(int)=sizeof(void *)=1 // 32-bits
> 
> It's a ... unique architectural feature.  :)

 I'm not sure it's that unique, though I do realise it's not that common 
these days either.

 Anyway, a symbol's size can be seen as an arithmetic difference between 
the next available address and the address of the symbol, so with an 
architecture defined like yours it looks to me you need to count in 32-bit 
quantities here.  Symbol sizes are not interpreted by generic ELF tools, 
except perhaps from presenting them to the user in dumps, but they may be 
processed by software run on the target such as by a dynamic loader for 
the purpose of processing copy relocations.  So using a data size 
measurement unit suitable for the target seems appropriate to me, so as 
not to incur unnecessary run-time overhead if nothing else.  If similar 
processing turns out then to be required in static linking as well, then 
the static linker can be adjusted accordingly in a target-specific manner.

 FWIW, GAS will set a `foo' symbol's size with an assembly language 
construct like this:

foo:
	# Symbol contents come here.
	.size	foo, . - foo

 HTH,

  Maciej