Re: Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions
On Fri, May 11, 2018 at 08:49:41PM +0200, John Paul Adrian Glaubitz wrote: > Hi! > > With Firefox 60.0 ESR now in experimental, most of the sparc64-related patches > are now part of the upstream source. > > The only patches we actually need are the one to fix skia on big-endian > targets > (I am currently in the process of upstreaming this one) and one tiny patch > to fix an alignment issue on sparc64. For the record, the latter was explicitly rejected. Mike
Re: Possible bug in GCC 5, need help
On Thu, Aug 20, 2015 at 08:17:27PM -0400, Stephen Powell wrote: On Sat, 15 Aug 2015 05:44:42 -0400 (EDT), Mike Hommey wrote: ... The current version of Iceweasel in unstable fails to build because of an internal error in the javascript engine which looks like it could be caused by some miscompilation. ... I was able to narrow it down as follows: ... - Building js/src/Parser.o with a #pragma GCC optimize(O0) at the beginning fixes it. - Then I was able to go down at the function level, whereby moving the following function at the end of the file and preceding it with the pragma above fixes it: template /* static */ bool ParserFullParseHandler::bindLexical(BindDataFullParseHandler* data, HandlePropertyName name, ParserFullParseHandler* parser) (somehow, adding a #pragma GCC optimize(O3) after a O0 one doesn't raise optimization level for the rest of the file, what's why I double checked by moving the function) Could someone with s390x assembly knowledge look at the assembly for that function and narrow it down further, possibly filing a GCC bug? If you will produce a compiler listing that shows the generated machine language and pseudo-assembly language for the problem piece of code, both for the good case and the failing case, and send me a link to it, I'll take a look at it. I can't promise you success, but I'll look at it. Sorry, I missed the answer because I'm not subscribed and forgot to check the ML. I'm not sure how useful this is going to be, but here you are: https://people.debian.org/~glandium/Parser.o.tar.gz Mike
Possible bug in GCC 5, need help
Hi, The current version of Iceweasel in unstable fails to build because of an internal error in the javascript engine which looks like it could be caused by some miscompilation. The same Iceweasel version doesn't exhibit the problem when compiled on stretch. An easier way to reproduce than to build iceweasel entirely is: - install autotools-dev and python - create a directory - in that directory, run: /path/to/iceweasel-source/js/src/configure --without-intl-api make - then run: dist/bin/js Normally, you'd get a js prompt. On a broken build, you see: self-hosted:16:0 InternalError: function nested too deeply: self-hosted:16:0 } self-hosted:16:0 ^ I was able to narrow it down as follows: - Building js/src/Parser.o only with GCC 4.9 and all the rest with GCC 5 fixes it. - Building js/src/Parser.o with a #pragma GCC optimize(O0) at the beginning fixes it. - Then I was able to go down at the function level, whereby moving the following function at the end of the file and preceding it with the pragma above fixes it: template /* static */ bool ParserFullParseHandler::bindLexical(BindDataFullParseHandler* data, HandlePropertyName name, ParserFullParseHandler* parser) (somehow, adding a #pragma GCC optimize(O3) after a O0 one doesn't raise optimization level for the rest of the file, what's why I double checked by moving the function) Could someone with s390x assembly knowledge look at the assembly for that function and narrow it down further, possibly filing a GCC bug? Thanks, Mike
Re: Differences between zelenka and zandonai
On Sun, Oct 31, 2010 at 01:42:39PM +0100, Philipp Kern wrote: On Sun, Oct 31, 2010 at 10:51:36AM +0100, Mike Hommey wrote: During the build, this is what happens: INFO | negative control allocated at 0x40028000 INFO | positive control allocated at 0x4002a000 INFO | poison area assumed at 0xf0dea000 (preferred addr) TEST-PASS | reading negative control TEST-PASS | executing negative control TEST-PASS | writing negative control TEST-PASS | reading positive control | Segmentation fault TEST-PASS | executing positive control | Segmentation fault TEST-PASS | writing positive control | Segmentation fault TEST-UNEXPECTED-FAIL | reading poison area TEST-PASS | executing poison area | Illegal instruction TEST-UNEXPECTED-FAIL | writing poison area It's interesting to see the addresses used for negative and positive control are significantly different, while running the program on zelenka and zandonai by hand give an address in 0x77xx. Could that be related to personality ? schroot should yield the same personality as for the buildd, given that the same chroot definition is used. I found the trigger: GNU make. I don't why, though. # cat test.mk foo: ./TestPoisonArea # make -f test.mk foo ./TestPoisonArea INFO | negative control allocated at 0x40021000 INFO | positive control allocated at 0x40023000 INFO | poison area assumed at 0xf0dea000 (preferred addr) TEST-PASS | reading negative control TEST-PASS | executing negative control TEST-PASS | writing negative control TEST-PASS | reading positive control | Segmentation fault TEST-PASS | executing positive control | Segmentation fault TEST-PASS | writing positive control | Segmentation fault TEST-UNEXPECTED-FAIL | reading poison area TEST-PASS | executing poison area | Illegal instruction TEST-UNEXPECTED-FAIL | writing poison area Mike -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101101090329.ga20...@glandium.org
Differences between zelenka and zandonai
Hi, Firefox uses a technique they call frame poisoning to mitigate dangling pointer bugs. It reserves a poison area at a fixed location in the address space (and tries other places if that can't be done) and makes dangling pointers point there so that the application ends up crashing instead of being exploitable. There is validation test in their test suite that verifies if that technique works properly. While upstream version doesn't support s390, adding support for it is pretty straightforward. The only problem I have now is that while this works properly on zelenka, it doesn't work on zandonai during the test suite run part of the build. Is there a difference in the kernel or hardware that would explain this behaviour? I'm attaching the test program in question. It can be simply built with g++ -o TestPoisonArea TestPoisonArea.cpp Thanks, Mike /* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */ /* vim:set ts=2 sw=2 sts=2 et cindent: */ /* * BEGIN LICENSE BLOCK * * Version: MPL 1.1/GPL 2.0/LGPL 2.1 * * The contents of this file are subject to the Mozilla Public License Version * 1.1 (the License); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * http://www.mozilla.org/MPL/ * * Software distributed under the License is distributed on an AS IS basis, * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License * for the specific language governing rights and limitations under the * License. * * The Original Code is frame poisoning tests. * * The Initial Developer of the Original Code is the Mozilla Foundation. * Portions created by the Initial Developer are Copyright (C) 2009 * the Initial Developer. All Rights Reserved. * * Contributor(s): * Zachary Weinberg zweinb...@mozilla.com * * Alternatively, the contents of this file may be used under the terms of * either the GNU General Public License Version 2 or later (the GPL), or * the GNU Lesser General Public License Version 2.1 or later (the LGPL), * in which case the provisions of the GPL or the LGPL are applicable instead * of those above. If you wish to allow use of your version of this file only * under the terms of either the GPL or the LGPL, and not to allow others to * use your version of this file under the terms of the MPL, indicate your * decision by deleting the provisions above and replace them with the notice * and other provisions required by the GPL or the LGPL. If you do not delete * the provisions above, a recipient may use your version of this file under * the terms of any one of the MPL, the GPL or the LGPL. * * * END LICENSE BLOCK * */ /* Code in this file needs to be kept in sync with code in nsPresArena.cpp. * * We want to use a fixed address for frame poisoning so that it is readily * identifiable in crash dumps. Whether such an address is available * without any special setup depends on the system configuration. * * All current 64-bit CPUs (with the possible exception of PowerPC64) * reserve the vast majority of the virtual address space for future * hardware extensions; valid addresses must be below some break point * between 2**48 and 2**54, depending on exactly which chip you have. Some * chips (notably amd64) also allow the use of the *highest* 2**48 -- 2**54 * addresses. Thus, if user space pointers are 64 bits wide, we can just * use an address outside this range, and no more is required. To * accommodate the chips that allow very high addresses to be valid, the * value chosen is close to 2**63 (that is, in the middle of the space). * * In most cases, a purely 32-bit operating system must reserve some * fraction of the address space for its own use. Contemporary 32-bit OSes * tend to take the high gigabyte or so (0xC000_ on up). If we can * prove that high addresses are reserved to the kernel, we can use an * address in that region. Unfortunately, not all 32-bit OSes do this; * OSX 10.4 might not, and it is unclear what mobile OSes are like * (some 32-bit CPUs make it very easy for the kernel to exist in its own * private address space). * * Furthermore, when a 32-bit user space process is running on a 64-bit * kernel, the operating system has no need to reserve any of the space that * the process can see, and generally does not do so. This is the scenario * of greatest concern, since it covers all contemporary OSX iterations * (10.5+) as well as Windows Vista and 7 on newer amd64 hardware. Linux on * amd64 is generally run as a pure 64-bit environment, but its 32-bit * compatibility mode also has this property. * * Thus, when user space pointers are 32 bits wide, we need to validate * our chosen address, and possibly *make* it a good poison address by * allocating a page around it and marking it inaccessible. The algorithm * for this is: * * 1. Attempt to make the page surrounding the poison address a reserved, *
Re: Differences between zelenka and zandonai
On Sun, Oct 31, 2010 at 10:38:06AM +0100, Philipp Kern wrote: Mike, am Sun, Oct 31, 2010 at 08:54:10AM +0100 hast du folgendes geschrieben: Firefox uses a technique they call frame poisoning to mitigate dangling pointer bugs. It reserves a poison area at a fixed location in the address space (and tries other places if that can't be done) and makes dangling pointers point there so that the application ends up crashing instead of being exploitable. There is validation test in their test suite that verifies if that technique works properly. While upstream version doesn't support s390, adding support for it is pretty straightforward. The only problem I have now is that while this works properly on zelenka, it doesn't work on zandonai during the test suite run part of the build. Is there a difference in the kernel or hardware that would explain this behaviour? they are hosted on the same physical box, so there's no difference in hardware at all. However, zandonai runs a backports kernel (2.6.32-bpo.5-s390x), and zelenka runs a release kernel (2.6.26-2-s390x). I don't know why that is. I'm attaching the test program in question. It can be simply built with g++ -o TestPoisonArea TestPoisonArea.cpp Simly compiling and running it does seem to work, however. (sid-s390-sbuild)bui...@zandonai:/build$ g++ -o TestPoisonArea TestPoisonArea.cpp (sid-s390-sbuild)bui...@zandonai:/build$ ./TestPoisonArea INFO | negative control allocated at 0x77fd9000 INFO | positive control allocated at 0x77cac000 INFO | poison area assumed at 0xf0dea000 (preferred addr) TEST-PASS | reading negative control TEST-PASS | executing negative control TEST-PASS | writing negative control TEST-PASS | reading positive control | Segmentation fault TEST-PASS | executing positive control | Segmentation fault TEST-PASS | writing positive control | Segmentation fault TEST-PASS | reading poison area | Segmentation fault TEST-PASS | executing poison area | Segmentation fault TEST-PASS | writing poison area | Segmentation fault During the build, this is what happens: INFO | negative control allocated at 0x40028000 INFO | positive control allocated at 0x4002a000 INFO | poison area assumed at 0xf0dea000 (preferred addr) TEST-PASS | reading negative control TEST-PASS | executing negative control TEST-PASS | writing negative control TEST-PASS | reading positive control | Segmentation fault TEST-PASS | executing positive control | Segmentation fault TEST-PASS | writing positive control | Segmentation fault TEST-UNEXPECTED-FAIL | reading poison area TEST-PASS | executing poison area | Illegal instruction TEST-UNEXPECTED-FAIL | writing poison area It's interesting to see the addresses used for negative and positive control are significantly different, while running the program on zelenka and zandonai by hand give an address in 0x77xx. Could that be related to personality ? Mike -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101031095136.ga6...@glandium.org
Re: Future of the s390 port
On Thu, Sep 03, 2009 at 12:16:53PM +0200, Bastian Blank wa...@debian.org wrote: On Thu, Sep 03, 2009 at 11:32:14AM +0200, Martin Grimm wrote: So as long as there is no easy manual way to provide anonymized figures without installing software on our production servers we can't deliver such data :-( Hmm. You could collect the /var/lib/dpkg/status files and do a mass submit with the data out of this files. It would lack the usage data, but at least shows something. Okay, this also depends on the condition that you don't consider the package names themself sensitive. That could surely grant a wishlist bug for popcon, to allow to, say, only report package names that are found in the debian archive. Mike -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Wed, Aug 19, 2009 at 04:33:32PM +0200, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote: On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. ... which will be needed anyways. So your choice is actually between doing it and doing it plus some extra intermediate work. Mike -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GCC 4.2 transition
On Fri, Jul 20, 2007 at 11:33:01AM +0200, Johannes Berg [EMAIL PROTECTED] wrote: On Fri, 2007-07-20 at 10:16 +0200, Matthias Klose wrote: Does any port still need to stick with GCC 4.1 for a while? Feedback from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show objections against the transition. I have objections :) http://bugs.debian.org/433629 Yes, it's pretty odd, but recompiling the whole kernel tree with gcc 4.2 causes my usbhid to totally not work. I have another objection. I'd like all mozilla security updates to be built before gcc 4.2 becomes the default, because they don't build correctly yet, and I am (still) waiting for an upstream comment on how to fix it. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
