On Mon, 7 Oct 2019 13:26:06 +0200 Ingo Molnar <mi...@kernel.org> wrote:
> [ Sorry, fixed the Cc:lkml line. ] /me joining the fun. > > * Peter Zijlstra <pet...@infradead.org> wrote: > > > These here patches are something I've been poking at for a while, > > enabling jump_label to use 2 byte jumps/nops. > > > > It _almost_ works :-/ > > > > That is, you can build some kernels with it (x86_64-defconfig for > > example works just fine). > > > > The problem comes when GCC generates a branch into another section, > > mostly .text.unlikely. At that point GAS just gives up and throws a fit > > (more details in the last patch). > > > > Aside from anyone coming up with a really clever GAS trick, I don't see > > how we can do this other than: > > > - use 'jmp' and get objtool to rewrite the text. Steven has earlier > > proposed > > something like that (using recordmcount) and Linus hated that. > > As long as GCC+GAS correctly generates a 2-byte or 5-byte JMP depending > on the target distance, the objtool solution should work fine, shouldn't > it? > > I can see the recordmcount solution sucking, it would depend on early > kernel patchery. But build time patchery is something we already depend > on, so assuming some objtool catastrophy it's a more robust solution, > isn't it? > Actually, even back then I said that it would be best to merge all the tools into one (I just didn't have the time to implement it), and then we could pull this off. I have one of my developers working to merge record-mcount into objtool now (there's been some patches floating around). Then with a single tool, it shouldn't be controversial. -- Steve
