Age | Commit message (Collapse) | Author |
|
On systems where /bin/sh is dash, this would lead to empty *.expected
and *.results files and thus make check would always succeed.
Closes: #1
|
|
|
|
|
|
The dladdr(3) explains that dladdr often doesn't do what you expect
because the function pointer will point to the PLT entry in the original
object and not the actual function itself.
|
|
|
|
Cherry-picked from Mesa commit 02e2009b929a (util/build-id: Fix address
comparison for binaries with LOAD vaddr > 0) by Stephan Gerhold.
|
|
|
|
|
|
From upstream Mesa commit a042465c218e ("util/build-id: define ElfW and
NT_GNU_BUILD_ID if needed")
|
|
|
|
In preparation for adding a "by_symbol" equivalent.
|
|
|
|
|
|
|
|
|
|
|
|
According to Mike Frysinger [1] it is not reliable to read ELF sections
at runtime, which the previous method involving the linker script was
doing.
Instead, use dl_iterate_phdr() to find the build id.
[1] https://sourceware.org/ml/binutils/2016-12/msg00207.html
|
|
Previously the build-id program (which was reading its own build-id
worked) but the so-build-id program (was was reading the linked DSO's
build id) did not.
I speculated that the __note_gnu_build_id_start symbol was not being
relocated properly since its address in the DSO was somewhat before the
.text section, while the __note_gnu_build_id_end symbol was correct. I
could even read the build-id which ended at the end symbol.
I noticed that in the output of "ld --verbose" that there is only a
".interp" section immediately before .note.gnu.build-id, while in "ld
--verbose -shared" there is nothing before .note.gnu.build-id. I think
that probably points to the problem, but I am not sure exactly what it
is.
|
|
|