Re: [FOUND] String offset errors on evbarm 8.99 [PR 54159]

[tlaronde%polynum.com@localhost]

On Mon, Aug 05, 2019 at 09:57:25PM +0200, Martin Husemann wrote:
> On Mon, Aug 05, 2019 at 08:51:12PM +0200, tlaronde%polynum.com@localhost wrote:
> > Yes. But the $d and $a are already preserved even in the .strtab section
> > when only the list is preserved and the others ($t and $t.x) are not
> > present even in the full table.
> 
> No thumb code in that lib, no big suprise. The theory this tested was that
> $a and $d are symbols with lots of values, which is quite uncommon and
> they are also special to arm object code. So good chance to be less tested
> and break.
> 

But there are other things.

Reading the .strtab with readelf -p .strtab when whe exported list is
given there are 102 entries, that correspond to the exported list 
plus $d and $a (the exported list is 100 entries).

The full .strtab, without the option of excluding what is not in the
list is 9923 entries.

But, when ld complains about the not full list it complains about
229 missing entries.

I have tried to convert the offset to hexadecimal and then to match
the full list. But it seems that my assumption was wrong since these
offsets do not correspond to offsets in the full table.

So there are still "some" symbols, that have an index but whose
corresponding string is not in the .strtab and this is not all the
symbols.

This, more or less, correspond  (in number) with all the symbols with a
leading p11 and since a lot of the strings in the "exported" list have
a matching prefix (p11_kit_pin_new, p11_kit_pin_new_for_buffer,
p11_kit_pin_new_for_string etc.) could it be that a part of the code
uses regular expressions (matching several strings) while another part
is using strict fixed strings so that the 100 strings used as regexp
end up matching 329 strings? Or alternatively there is a hash function
with only a fixed number of leading characters and several strings end
in the same entry (this is a shot in the dark since I was unable
to find some pattern that would give me the missing 229 from the
full list).

-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C