On Fri, May 19, 2017 at 10:23 PM, Andy Lutomirski <luto@xxxxxxxxxx> wrote:
>
> I personally like the idea of using real DWARF annotations in the
> entry code because it makes gdb work better (not kgdb -- real gdb
> attached to KVM). I bet that we could get entry asm annotations into
> good shape if we really wanted to. OTOH, getting DWARF to work well
> for inline asm is really nasty IIRC.
No. I will NAK *any* attempt to make our asm contain the crazy
shit-for-brains annotations.
Been there, done that, got the T-shirt, and then doused the T-shirt in
gasoline and put it on fire.
The amount of unreadable crap and bugs it requires is not worth the
pain. Not for *any* amount of gain, and the gain here is basically
zero.
> (H.J., could we get a binutils feature that allows is to do:
>
> pushq %whatever
> .cfi_adjust_sp -8
> ...
> popq %whatever
> .cfi_adjust_sp 8
>
> that will emit the right DWARF instructions regardless of whether
> there's a frame pointer or not? .cfi_adjust_cfa_offset is not
> particularly helpful here because it's totally wrong if the CFA is
> currently being computed based on BP.)
Yeah, that's just a small example of the kind of crap people have to deal with.
Not going to happen. Assembler files are hard enough to write (and
read) as-is, anything that expects us to go back to the bad old days
with crazy shit cfi annotations is going to get violently NAK'ed and
vetoed forever.
The *only* acceptable model is automated tools (ie objtool). Don't
even bother to try to go any other way. Because I will not accept that
shit.
Linus
--
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
