@d-e-s-o @ work
@d-e-s-o @ work
So checking https://en.wikipedia.org/w/index.php?title=Data_structure_alignment&oldid=1209741102#Typical_alignment_of_C_structs_on_x86 it appears as if 4 byte alignment for 8 byte words may be actually valid for C, meaning that they don't really require natural alignment. In that...
Can you retry with https://github.com/libbpf/blazesym/commit/247c4c512ac784a99fbffde6ce07e85db9e15991 ? I'd think that will fix the issue.
That would mean stack walking and evaluating of CFI, right? I don't think there are plans for that right now, but it could reasonably be part of the library, I'd...
The problem here may be that `llvm-symbolizer` is a binary that we exec and so we have process spawn overhead. Perhaps there is a lower level LLVM library we could...
Makes sense and would certainly be better. I'd still be a tad cautious that we are comparing apples to apples though, because we'd still have waiting-for and parsing of input...
FWIW, this seems to be how `addr2line` benchmarks various tools: https://github.com/gimli-rs/addr2line/blob/dda39c4106ef82aa33c4f6538019789cd88bc69c/benchmark.sh
Our string lookup logic is also questionable. See https://github.com/libbpf/blazesym/pull/190#discussion_r1212089043
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...
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...
The more I think about it and look at the original approach, the less I like it and the more I think it is not suitable given our architecture. Our...