On Fri, Mar 23, 2018 at 9:38 PM, YunQiang Su <wzss...@gmail.com> wrote: > On Fri, Mar 23, 2018 at 8:41 PM, Sébastien Villemot > <sebast...@debian.org> wrote: >> On Fri, Mar 23, 2018 at 08:02:58PM +0800, YunQiang Su wrote: >>> On Fri, Mar 23, 2018 at 7:58 PM, YunQiang Su <wzss...@gmail.com> wrote: >>> > On Fri, Mar 23, 2018 at 7:27 PM, Sébastien Villemot >>> > <sebast...@debian.org> wrote: >>> >> Dear YunQiang, >>> >> >>> >> On Fri, Mar 23, 2018 at 06:15:08PM +0800, YunQiang Su wrote: >>> >>> Package: src:ffcall >>> >>> Version: 2.1-1 >>> >>> >>> >>> MIPS release 6 drops some instructions: bnel/beql included. >>> >>> For r6, we should use bne/beq for replace. >>> >>> >>> >>> The patch has submit in salsa as a merge request. >>> >>> >>> >>> https://salsa.debian.org/common-lisp-team/ffcall/merge_requests/1 >>> >> >>> >> Thanks for your report and your patch. >>> >> >>> >> You may have overlooked the fact that these assembly files are actually >>> >> generated by GCC from C source code (see the DEP-3 header of >>> >> debian/patches/mips-fpxx.patch), so your proposed patch is not very >>> >> maintainable in the long term. >>> > >>> > Oh, thanks. Since then, I guess we should generate these .S files >>> > when build instead of put them in the source code. >>> > >>> > I will have a look at it. >>> >>> After read Makefile.devel, I think that we should call the right >>> target in debian/rules. >>> Should this the ideal way? >> >> This could be a possiblity, but this is not supported by upstream. And we >> would >> have to patch this Makefile.devel to make it work (it expects non-standard >> names for GCC). So I do not really like this solution. >> > > In fact we can patch it to use $(CC), and pass it when we call these targets, > and then we can drop the patch for the .S/.s files. > The length of patch file will be much shorter.
If we figure out a command $(CROSS_TOOL) which can has options like "mips64-linux gcc", then the patch can be even shorter. > > Anyway, we will have to patch it. > Wish my attached patch can change your mind. ;) > >> Another possibility, that I would prefer, is to treat mipsr6 as a different >> ABI >> (which it actually is), adding the corresponding *.S files with a patch. Do >> you >> think this is feasible? > > The patch work may be much bigger than the solution 1. > and the patch will be much longer. > If you still prefer this solution, I will try to figure out a patch. > >> >> If not, then I think I still prefer to incorporate the first version of your >> patch. >> >> -- >> ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot >> ⣾⠁⢠⠒⠀⣿⡁ Debian Developer >> ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name >> ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org > > > > -- > YunQiang Su -- YunQiang Su