Incomplete ELF support

[d-e-s-o]

It appears as if the ELF parser does not handle all possible values of e_shstrndx correctly:

https://github.com/libbpf/blazesym/blob/master/src/elf/parser.rs#L192-L207

ELF(5) states:

       e_shstrndx
              This  member  holds the section header table index of the entry associ‐
              ated with the section name string table.  If the file  has  no  section
              name string table, this member holds the value SHN_UNDEF.

              If  the  index  of  section name string table section is larger than or
              equal to SHN_LORESERVE (0xff00), this member holds SHN_XINDEX  (0xffff)
              and  the real index of the section name string table section is held in
              the sh_link member of the initial entry in section header table.   Oth‐
              erwise, the sh_link member of the initial entry in section header table
              contains the value zero.

So we may have to special case SHN_XINDEX.

[danielocfb]

Our string lookup logic is also questionable. See https://github.com/libbpf/blazesym/pull/190#discussion_r1212089043

[danielocfb]

For reference, over in https://github.com/libbpf/blazesym/pull/384#pullrequestreview-1709204144 the following case was also mentioned:

For extended program header table numbering the scheme is similar, with the e_phnum field of the executable header holding the value PN_XNUM (0xFFFF) and the sh_link field of the zeroth section header table holding the actual number of program header table entries.

[danielocfb]

We should also check what happens when there are more than 0xffff sections and we try to access one via the Elf64_Sym.st_shndx member (which is 16 bits in size). See https://github.com/libbpf/blazesym/pull/389#discussion_r1379425619

[d-e-s-o]

I am going ahead and close this issue. All points accumulated in this task have been addressed, except for the more than 0xffff sections thing. My point of view there is, if it's not in the ELF spec it's hypothetical. Yes, practical implementations could conceivably have work arounds, but let's go there when we have a case. Even with large production binaries, my hunch is (and that's probably shared with the authors of the spec itself, given that they didn't change the type with the introduction of ELF64) that 64k sections is quite a bar...

The only one "issue" that comes to mind is that we may not want to rely on the symbol table being named .symtab (similar for other tables that we look up by name). Will treat that separately, though.