https://bugs.kde.org/show_bug.cgi?id=452758
--- Comment #42 from Lubos Lunak <l.lu...@kde.org> --- > 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. -- You are receiving this mail because: You are watching all bug changes.
