This is an archive of the discontinued LLVM Phabricator instance.

[lld][ELF][ARM] Generate PLT entries for function calls from ARM and Thumb code
ClosedPublic

Authored by denis-protivensky on Mar 30 2015, 6:52 AM.

Details

Summary

The function call that goes through PLT table may be performed from both ARM and Thumb code. This situation requires adding a veneer to original PLT code (which is always ARM) to effect Thumb-to-ARM transition.

Diff Detail

Repository
rL LLVM

Event Timeline

denis-protivensky retitled this revision from to [lld][ELF][ARM] Generate PLT entries for function calls from ARM and Thumb code.
denis-protivensky updated this object.
denis-protivensky edited the test plan for this revision. (Show Details)
denis-protivensky added reviewers: shankarke, ruiu.
denis-protivensky added a project: lld.
denis-protivensky added a subscriber: Unknown Object (MLST).
ruiu accepted this revision.Mar 30 2015, 1:51 PM
ruiu edited edge metadata.

LGTM

lib/ReaderWriter/ELF/ARM/ARMRelocationPass.cpp
125 ↗(On Diff #22880)

We usually put protected members after public members. You may want to move this for consistency.

378 ↗(On Diff #22880)

Maybe this is enough?

StringRef source;
#ifndef NDEBUG
source = "_ifunc_";
#endif
This revision is now accepted and ready to land.Mar 30 2015, 1:51 PM

Thanks for reviewing, Rui!

lib/ReaderWriter/ELF/ARM/ARMRelocationPass.cpp
125 ↗(On Diff #22880)

Didn't want to move the constructor to the bottom of the class, but that's not a big deal. Will do.

378 ↗(On Diff #22880)

Right.

shankarke added inline comments.Mar 31 2015, 8:58 AM
lib/ReaderWriter/ELF/ARM/ARMRelocationPass.cpp
296–308 ↗(On Diff #22880)

Isnt a seperate entry in the PLT for a thumb call preferred ?

555–556 ↗(On Diff #22880)

Say for example you call the same atom from thumb/arm, the current code would reuse the veneer generated by ARM for thumb too, is this correct ?

lib/ReaderWriter/ELF/ARM/ARMRelocationPass.cpp
296–308 ↗(On Diff #22880)

When the same atom is called through PLT from both ARM and Thumb, it's enough to generate one PLT with transition code on top of it. ARM code will reference ARM instructions while Thumb code will first execute instruction mode switch. Obviously, I first implemented separate PLTs for ARM & Thumb, but then saw how gcc handles it in one PLT entry and decided that it's more optimal.

555–556 ↗(On Diff #22880)

When the same atom is called from both modes, the one mode will call the code directly as mode switch is not needed, and the other will use the veneer generated. The conditions for veneer generation are checked in handleVeneer method, while this method only creates a veneer when requested.

Thanks for the explanation. LGTM.

This revision was automatically updated to reflect the committed changes.