mirror of
https://github.com/AdaCore/aws.git
synced 2026-02-12 12:29:46 -08:00
e97f27078a
On PPC systems, HTTP2 & HPACK testcases were failing because
AWS.HTTP2.HPACK.Huffman.Decode was raising Protocol_Errors over inconsistent
padding.
The encoded bytestrings were correct; things were diverging in
AWS.HTTP2.HPACK.Decode, where bytes were misinterpreted when read as
RFC_Byte, due to that record's representation clause being target-dependent.
For example, if we break in that function right as it processes the first
byte of an encoded string, and that first byte is decimal integer 130…
256 Byte := Get_Byte;
(gdb) next
258 if Bit.B0 = 1 then
(gdb) p/t byte
$8 = 10000010
In RFC_Byte's "Bₙ at 0 range i .. j" component clauses, by default, i and j
are interpreted differently depending on which bit ordering the target uses.
Thus on a little-endian platform like x86_64-linux:
(gdb) p/t bit
$9 = (
b7 => 0,
b6 => 1,
b5 => 0,
b4 => 0,
b3 => 0,
b2 => 0,
b1 => 0,
b0 => 1,
b23 => 10,
b22 => 0,
b21 => 0,
b20 => 10,
b30 => 100,
b41 => 10,
b40 => 1000
)
Whereas on a big-endian platform such as ppc64-linux:
(gdb) p/t bit
$9 = (
b7 => 1,
b6 => 0,
b5 => 0,
b4 => 0,
b3 => 0,
b2 => 0,
b1 => 1,
b0 => 0,
b23 => 10,
b22 => 0,
b21 => 0,
b20 => 10,
b30 => 10,
b41 => 1000,
b40 => 10
)
Fix this by picking an explicit Bit_Order for RFC_Byte, so that in those
range clauses, i and j are interpreted consistently across all platforms
(i.e. pick Low_Order_First so that "0" refers to the MSb, "7" to the LSb).
Also fix AWS.HTTP2.HPACK.Huffman.Decode, which presents a similar problem: a
Stream_Element is aliased as an array of bits, but the indexing order of that
array will depend on endianness. Use a similar solution to
2023-03-21 "Fix creation of Huffman decoding tree for big-endian
platforms" (7eca5a10c)
That is, remove the aliasing array type, and rely on platform-independent
shifts.
TN: eng/toolchain/aws#4