Hi Ard, On Wed, Mar 6, 2024 at 9:11 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Wed, 6 Mar 2024 at 14:08, yunhui cui <cuiyunhui@xxxxxxxxxxxxx> wrote: > > > > Hi Jan, > > > > On Wed, Mar 6, 2024 at 8:52 PM Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: > > > > > > On 06.03.24 09:56, Yunhui Cui wrote: > > > > This reverts commit afb2a4fb84555ef9e61061f6ea63ed7087b295d5. > > > > > > > > > > This comes without a reason - which is likely something around "will fix > > > this properly later". But then you regress first and only fix > > > afterwards. Can't that be done the other way around? > > > > Sorry, I don't quite understand what you mean. Can you help explain it > > more clearly? Do you mean "delete mno-relax instead of revert > > directly?" > > > > You should order your patches in a way that does not create > intermediate states (between 1-2 or between 2-3) where the original > problem is being recreated. > > So in this case, you should > a) fix the issue > b) revert the existing patches in *opposite* order Simply, I plan to remove "-mno-relax" and "\|R_RISCV_$(BITS)\|R_RISCV_RELAX" in the third patch (fix patch). > However, I don't think the EFI stub can use GP - please refer to my other reply. The problem we encountered is that gcc 13 will optimize efistub using gp. Thanks, Yunhui
