Messages in this thread | | | Date | Mon, 7 Oct 2019 14:07:56 +0200 | From | Peter Zijlstra <> | Subject | Re: [RFC][PATCH 0/9] Variable size jump_label support |
| |
In the failed thread Ingo posted:
>On Mon, Oct 07, 2019 at 01:26:06PM +0200, Ingo Molnar wrote: > * Peter Zijlstra <peterz@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?
IIRC the recordmcount variant from Steve was also rewriting JMP8 to NOP2 at build time.
I dug this here link out of my IRC logs:
https://lore.kernel.org/lkml/1318007374.4729.58.camel@gandalf.stny.rr.com/
Looking at that, part of the reason might've been running yet another tool, instead of having one tool do everything.
| |