Messages in this thread | | | Subject | Re: [PATCH 1/3] LoongArch: tools: Add relocs tool support | From | Xi Ruoyao <> | Date | Sun, 04 Sep 2022 00:53:34 +0800 |
| |
On Sun, 2022-09-04 at 00:23 +0800, Jinyang He wrote: > On 2022/9/3 18:49, Xi Ruoyao wrote: > > > On Sat, 2022-09-03 at 09:57 +0800, Youling Tang wrote: > > > > > Unlike (pre-r6) MIPS, LoongArch has a complete support for PIC, and > > > > > currently LoongArch toolchain always produces PIC (except, if -Wa,-mla- > > > > > {local,global}-with-abs or la.abs macros are used explicitly). > > > > > > > > > > So would it be easier to review and correct the uses of "la.abs" in the > > > > > code, and make the main kernel image a real PIE? Then we can load it > > > > > everywhere w/o any need to do relocation at load time. > > > At the beginning I also wanted to make the main kernel image a real PIE > > > and tried it, some of the "la.abs" can be modified, but I encountered > > > difficulties in modifying the exception handling code part, the kernel > > > will not boot after modification :(, I will continue to work hard try.
> > I just tried the same thing and get the same result :(. Will spend > > several hours reading the LoongArch manual about exception...
The reason is the handler code is not executed in linker address, but copied elsewhere. Then PC-relative offset is broken. I managed to work around it by creating a trampoline and jump into the handler, instead of copy the handler code. Then I could remove most "la.abs" occurrence (except two in kernel entry point, which seem deliberately used):
- https://github.com/xry111/linux/commit/56a433f - https://github.com/xry111/linux/commit/48203e6
Using the trampoline in handler table will definitely lead to sub- optimal performance. I just use it as a proof-of-concept. Later we may use some assembler trick to generate hard-coded handler table with correct PC-relative offsets.
> The following ideas are based on experience, without validation. Patches > show that three types of relocation are needed to be done. > 1, GOT is generated by toolchain, so I think eliminating them by > toolchain is better.
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600797.html
I stop to read the mail here because it's 00:52 AM now :).
> 2, Ex_table is generated but striped relocation info. We can plays pcrel > way to resolve this problem. One of ways like follows, (pseudo-code)
/* snip */
-- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University
| |