This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ELF octets_per_byte

Hi Pedro, and GDB-land...

> GDB 7.11 gained support for this,

As a matter of interest, can I bring up the issue of DWARF and LEB128 encoding ?

According to the DWARF 4 specification:

  7.6 Variable Length Data

  Unsigned LEB128 (ULEB128) numbers are encoded as follows: start at 
  the low order end of an unsigned integer and chop it into 7-bit chunks.
  Place each chunk into the low order 7 bits of a byte. Typically, 
  several of the high order bytes will be zero; discard them. Emit the
  remaining bytes in a stream, starting with the low order byte; set 
  the high order bit on each byte except the last emitted byte. The 
  high bit of zero on the last byte indicates to the decoder that it has
  encountered the last byte.

Note the use of the word "byte" here.  I could not find any reference to octets
in the document, but I think that the implication is that a byte is the smallest
addressable storage unit available on the target architecture, and not necessarily
always an 8-bit quantity.  This does mean however that for targets with 32-bit 
bytes for example, LEB128 encoding is very wasteful of space...

If the specification intends that a "byte" is an 8-bit quantity then it needs to 
specify how these 8-bit values are stored into a target storage unit when the 
storage unit is larger than 8 bits, (ie little endian vs big endian).  Plus it 
should state whether a LEB128 value is padded out to fill a whole number of 
storage units, or if they are packed in as tightly as possible.  Plus the 
algorithm in Appendix C ought to be extended to reference packing octets into 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]