On 2/17/21 10:12 AM, Jose E. Marchesi wrote:
In the recent work with btf.pk that David Faust did, we have
something
like this:
type BTF_Section =
struct
{
[...]
string[header.str_len] strings @ str_off;
/* Given an offset into the BTF strings section, return the
string. */
method get_string = (offset<uint<32>,B> off) string:
{
return string @ strings'offset + off;
}
};
i.e. the string table in the BTF section can be comfortably
expressed as
an array of strings.
But then, in the BTF world strings are referred using an offset
relative
to the string table, and not the ordinal order of the string in the
table. This is similar to other string tables in other formats like
ELF.
The method above works, but it has a problem: it is not what I call
"agnostic" Poke code. This means that the code needs assumes the data
is mapped. In this case, the method only works when invoked in a BTF
section that is mapped.
Most Poke code should be agnostic if needed, so I am proposing two
additions to the language:
1) Indexing array values with offsets.
We shall support indexing arrays, both mapped and non-mapped,
with an
offset value. Like in:
var a = [1,2,3];
a[0#B] -> 1
a[4#B] -> 2
a[8#B] -> 3
The provided offset should match the offset of some particular
element in the array. Otherwise, we get an E_out_of_bounds
exception:
a[5#B] -> raises E_out_of_bounds
a[10#Kb] -> raises E_out_of_bounds
Using this support, we don't need the `get_string' method above.
Given an offset into the string table the user can just do:
section.strings[OFFSET]
which would be agnostic Poke code: it would work as well with
both
mapped and non-mapped BTF sections.
It makes sense to consolidate the semantics for array access using
offset for both mapped and non-mapped arrays.
Regarding the error: as a user, a first reaction when I see a
E_out_of_bounds for a[5#B] is confusing because the access is within
bounds, it just happens to be an invalid one.
How about :
a[5#B] -> raises E_invalid_access
a[10#Kb] -> raises E_out_of_bounds