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
HPACK Encoder was not able to use dynamic tables.
Optimize HPACK Decoder.
No need Rank and Index together. For the Static table we need Index.
For the Dynamic table we need Rank only.
Part of S507-051.
