Bug#834844: release-notes: document that mips* arches now require a R2 CPU
On 08/25/2016 06:42 AM, James Cowgill wrote: Hi, On 25/08/16 14:17, Ed Swierk wrote: This mips32r2 requirement also appears to exclude Cavium Octeon: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/include/asm/mach-cavium-octeon/cpu-feature-overrides.h#n50 If that's accurate, it would be worth mentioning in the release notes as well. *sigh* Cavium Octeon machines do support R2 (mips32r2 is a subset of mips64r2) but for some reason unknown to me, don't actually expose this. I've adjusted the check to look for mips64r2 as well and attached a new patch. Yes, *all* OCTEON CPUs have always been r2 (or better). At the time the code was written, there were good reasons not to set: #define cpu_has_mips32r2 0 This was discussed on the lmo mailing lists, but I forget what they were at this point. David Daney Thanks, James On Thu, Aug 25, 2016 at 4:10 AM, James Cowgill <jcowg...@debian.org> wrote: Control: tags -1 patch On 19/08/16 22:42, Aurelien Jarno wrote: This is something to be expected as the mips and mipsel port now defaults to using R2 instructions set. This means the Loongson 2 CPUs are not supported anymore (this includes the Yeeloong machine). I have asked many times to document this changes in the release notes, but this hasn't been done yet. I am therefore reassigning the bug there, Cc:ing debian-mips so that somone can take care of that. How about the attached patch? It's loosely based on the i686 notes just above. I also changed the "human readable" mips architecture names since all the other arches seem to have them. James
Bug#600223: python-rdflib: fails with SIGBUS on mipsel - breaks build of enigmail
On 10/16/2010 02:30 AM, Matthias Klose wrote: severity 600223 wishlist tag 600223 + moreinfo thanks the bug report in its current form has little value. - recheck with gcc-4.5, gcc-snapshot - combine the object files of a build with -O0 and -O2 to find the file with the issue. - maybe reduce it further, find the reason about this SIGBUS, and if it's a compiler issue at all. It is a userspace program that is generating SIGBUS. Why not attach gdb and get a dissassembly of the region of code that is crashing as well as backtraces and register contents? David Daney -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516616: bind9 locks up on start on mipsel and mips
On 03/11/2010 03:41 AM, Steven Luo wrote: On Thu, Mar 11, 2010 at 12:06:11AM +0200, Niko Tyni wrote: - addu %0, $1, %2 \n + addu %0, $0, $1 \n Would it be better to use move %0, $1 (as in isc_atomic_cmpxchg())? That seems to be functionally equivalent. I was going to suggest the same thing. It makes it more clear what is happening. Not only is MOVE functionally equivalent, it is causes the exact same code to be emitted, so you might say it is identical. David Daney -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536676: plink: FTBFS on MIPS.
Charles Plessy wrote: Le Tue, Jul 14, 2009 at 08:01:34AM +0200, Luk Claes a écrit : Charles Plessy wrote: How about trying to separate the issues of having a bug in GCC and having a package that does not build on MIPS? I noticed that the package is built with -O3, which probably unnecessary. Can somebody try to build plink with -O2 on MIPS to see if it escapes the bug? The following patch in debian/rules would to the job: You do know that you can try this yourself on mahler.d.o, right? Sure, but since plink seems to be fine on other architectures, this bug seems more relevant to MIPS than to plink. I do not think that anybody on Earth is interested to use plink on MIPS. So if it helped you to find a MIPS-relevant bug, I am happy, but if you (the MIPS porters) are not interested in solving it, I would rather not distribute this package on MIPS than accept the responsibility for managing a GCC bug, which is completely outside my field of competence. Said differently, if this bug is zero fun for everybody let's find a solution that allow us to focus on what we care the most. Can you file a bug report as per GCC bug reporting guidelines: http://gcc.gnu.org/bugs.html We will try to fix it if it affects current GCC versions. Especially helpful would be preprocessed source and the exact command line flags used. Thanks, David Daney -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531939: FTBFS on mipsel due to missing -fPIC
Luk Claes wrote: Giuseppe Iuculano wrote: Hi, Luk Claes ha scritto: mips and mipsel do now also need the -fPIC compilation flag to make sure that shared objects only contain position independent code. c++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -g -O2 -DDEBIAN -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O2 -fno-strict-aliasing -g -fPIC -shared -Wl,-z,defs -Wl,-h,libxpcom_core.so -o libxpcom_core.so pldhash.o nsCOMPtr.o nsComponentManagerUtils.o nsDebug.o nsID.o nsIInterfaceRequestorUtils.o nsINIParser.o nsMemory.o nsTraceRefcnt.o nsWeakReference.o nsGREGlue.o nsVersionComparator.o nsTHashtable.o nsTArray.o nsGenericFactory.o nsXPComInit.o nsStringAPI.o-Wl,--as-needed -Wl,--whole-archive ../../dist/lib/libxpcomds_s.a ../../dist/lib/libxpcomio_s.a ../../dist/lib/libxpcomcomponents_s.a ../../dist/lib/libxpcomthreads_s.a ../../dist/lib/libxpcomproxy_s.a ../../dist/lib/libxpcombase_s.a ../../dist/lib/libxptcall.a ../../dist/lib/libxptinfo.a ../../dist/lib/libxpt.a ../../dist/lib/libxptcmd.a ../../dist/lib/libstring_s.a -Wl,--no- w h ole-archive -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -ldl -lm /usr/bin/ld: ../../dist/lib/libxptcmd.a(xptcinvoke_asm_mips.o): relocation R_MIPS_HI16 against `__gnu_local_gp' can not be used when making a shared object; recompile with -fPIC ../../dist/lib/libxptcmd.a(xptcinvoke_asm_mips.o): could not read symbols: Bad value The -fPIC is included, or am I missing something? Hmm, very strange. Is this a mips specific bug in binutils? No, the symbol __gnu_local_gp is generated by GCC. *All* modules linked into a shared library must be compiled with -fPIC *and* you must not use -mshared. It would appear that these requirements were not met when xptcinvoke_asm_mips.o (which is a member of ../../dist/lib/libxptcmd.a) was compiled. David Daney -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531939: FTBFS on mipsel due to missing -fPIC
David Daney wrote: Luk Claes wrote: Giuseppe Iuculano wrote: Hi, Luk Claes ha scritto: mips and mipsel do now also need the -fPIC compilation flag to make sure that shared objects only contain position independent code. c++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -g -O2 -DDEBIAN -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O2 -fno-strict-aliasing -g -fPIC -shared -Wl,-z,defs -Wl,-h,libxpcom_core.so -o libxpcom_core.so pldhash.o nsCOMPtr.o nsComponentManagerUtils.o nsDebug.o nsID.o nsIInterfaceRequestorUtils.o nsINIParser.o nsMemory.o nsTraceRefcnt.o nsWeakReference.o nsGREGlue.o nsVersionComparator.o nsTHashtable.o nsTArray.o nsGenericFactory.o nsXPComInit.o nsStringAPI.o-Wl,--as-needed -Wl,--whole-archive ../../dist/lib/libxpcomds_s.a ../../dist/lib/libxpcomio_s.a ../../dist/lib/libxpcomcomponents_s.a ../../dist/lib/libxpcomthreads_s.a ../../dist/lib/libxpcomproxy_s.a ../../dist/lib/libxpcombase_s.a ../../dist/lib/libxptcall.a ../../dist/lib/libxptinfo.a ../../dist/lib/libxpt.a ../../dist/lib/libxptcmd.a ../../dist/lib/libstring_s.a -Wl,--no- w h ole-archive -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -ldl -lm /usr/bin/ld: ../../dist/lib/libxptcmd.a(xptcinvoke_asm_mips.o): relocation R_MIPS_HI16 against `__gnu_local_gp' can not be used when making a shared object; recompile with -fPIC ../../dist/lib/libxptcmd.a(xptcinvoke_asm_mips.o): could not read symbols: Bad value The -fPIC is included, or am I missing something? Hmm, very strange. Is this a mips specific bug in binutils? No, the symbol __gnu_local_gp is generated by GCC. *All* modules linked into a shared library must be compiled with -fPIC *and* you must not use -mshared. s/-mshared/-mno-shared/ Better proofreading is in order. It would appear that these requirements were not met when xptcinvoke_asm_mips.o (which is a member of ../../dist/lib/libxptcmd.a) was compiled. David Daney -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
