Re: [PATCH 1/1] x86: fix text_poke

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Miller wrote:
From: "H. Peter Anvin" <hpa@xxxxxxxxx>
Date: Fri, 25 Apr 2008 13:41:00 -0700

Yes, that should work. It's still ugly, and I have to say I find the complexity rather distasteful. I am willing to be convinced it's worth it, but I would really like to see hard numbers.

This stuff would have been a lot easier if it just worked with
normal relocations generated by the assembler, and that would
work in such a straightforward way on EVERY architecture.

The immediate instance generators could just use macros that
architectures define, which are given a range of legal values for the
immediate, and the macro emits the inline asm sequence that can
support an immediate value of that range.

Then we do a half-link of the kernel, collect the unresolved
relocations from generated by the immediate macros into a table which
gets linked into the kernel, then resolve them in the final link all
to zero or some defined initial value.

Then it's just a matter of running through the relocation handling
we already have for module loading when changing an immediate
value.

None of this crazy instruction parsing and branch following crap.
I can't believe we're seriously considering this crud. :-/

That's already there, for all practical purposes. The point of contention here is trying to go from immediate value rewriting to branch rewriting, which is probably the vast majority of all desired uses. However, branch rewriting affects the flow of control, and flow of control is inherently vital for gcc to understand.

I'm not inherently opposed to branch target rewriting, but I believe gcc really needs to be involved in the process. On systems compiled with older compilers, we just won't use that feature -- similar to most other features introduced in a new compiler.

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux