Comment 43 for bug 1995274

> It looks almost correct. I would just remove the following debug (TD3) part
> from get_debug_addr_entry_common:

Updated.

> It is a little tricky to know how to interpret endianness for these "3-byte"
> values.
> But what I mean is that I believe others interpret this as a 4-byte value
> where the 4th byte is zero.
> Which doesn't matter for little endian, but does for big endian.
> With the assumption of the 4th byte is zero the code would look like:
>
> c1 = ML_(img_get_UChar)(c->sli.img, c->sli_next);
> c2 = ML_(img_get_UChar)(c->sli.img, c->sli_next+1);
> c3 = ML_(img_get_UChar)(c->sli.img, c->sli_next+2);
> c4 = 0;
> c->sli_next += 3;
> #if defined(VG_BIGENDIAN)
> return c1 << 24 | c2 << 16 | c3 << 8 | c4;
> #else
> return c1 | c2 << 8 | c3 << 16 | c4 << 24;
> #endif

I don't see the dwarf spec being specific on how to interpret this, but then I think my way is the only logical one. This code would be weird/broken, for the following reasons:
- It's inconsistent between little and big endian. On LE this would encode offsets 0-16777215, on BE it would encode offsets in multiples of 256 in the range 0-4278190080.
- It's inconsistent with the 1,2,4 variants. Those encode 1,2,4 lowest bytes (e.g. str2 doesn't mean 3rd and 4th byte being zero).
- It doesn't make much sense to encode multiples of 256. Although it's not spelled out, I think it's clear that it's meant to be a binary representation of a value using the minimal number of bytes needed.