On Wed, Jun 10, 2015 at 01:58:45PM -0500, Josh Poimboeuf wrote: > On Wed, Jun 10, 2015 at 11:15:19AM -0700, Andy Lutomirski wrote: > > On Wed, Jun 10, 2015 at 10:53 AM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > > On Wed, Jun 10, 2015 at 10:21:36AM -0700, Andy Lutomirski wrote: > > >> GCC can generate those, and the ia32_ptregs_common label is an example > > >> of such a thing. > > >> > > >> I'd rather have the script understand tail calls and possibly require > > >> that ia32_ptregs_common have a dummy frame pointer save in front > > >> before the label if needed. > > > > > > Why do you prefer tail calls there? See patch 3 for how I handled that > > > for ia32_ptregs_common (I duplicated the code with macros). > > > > > > I think adding support for tail calls in the tooling would be tricky. > > > So I'm just trying to figure out if there's a good reason to keep them. > > > > To save code size by deduplicating common tails. The code currently > > does that, and it would be nice to avoid bloating the code to keep the > > validator happy. > > Well, I wonder whether it's really worth sacrificing code readability > and consistency, and maybe some improved i-cache locality, to save a few > hundred bytes of code size. I should also mention that my proposed ia32_ptregs_common patch, which duplicated the needed code, was more optimized for performance than code size. But if you're more worried about code size, we could turn ia32_ptregs_common into a proper callable function, and then replace jmp ia32_ptregs_common with: call ia32_ptregs_common ret So it becomes a regular call instead of a tail call. It only adds a few instructions and the function is self-contained. Would that be good enough? -- Josh -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
