You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our PLT parsing mechanism on ARM is not doing the right thing, and is quite brittle. We should follow what the linker does in its generation of PLT stubs rather than relying on magic numbers/sizes/instruction sequences wherever possible.
The text was updated successfully, but these errors were encountered:
Fix this issue by skipping the first two plt entry size on ARM #37.
This is not the ideal fix, but our alternative does not work. We tried to look up symbols in the .dynsym section to locate the address of a PLT stub, but this method would fail as there could be a PLT stub and a function in .text and these two have the same name; the symbol in .dynsym points to the function entry in the .text section. Therefore, we cannot determine the location of PLT stubs by looking at .dynsym
Our PLT parsing mechanism on ARM is not doing the right thing, and is quite brittle. We should follow what the linker does in its generation of PLT stubs rather than relying on magic numbers/sizes/instruction sequences wherever possible.
The text was updated successfully, but these errors were encountered: