On Sat, 30 Jan 2010 15:26:51 Bill Hart wrote: > > It is a bit more subtle than that, it should work most of the time. The > > main case where things could go south is if you have a hardened system > > with the NX bit turned on - my guess. > > It is a QA issue meaning that actual side effects are hard to predict > > depending on what is actually done. The check just points out to "bad > > practise". > > I see. Well I added the recommended defines to one of the yasm > assembler files and that didn't cause it to bomb out, so assuming this > has no performance side effects, I guess it would be possible to write > a script to update all the assembler files in MPIR (there's hundreds > of them, so you don't want to do it by hand). >
I have no idea if there is an impact on performance I must say. I don't think it would but I am not a specialist in assembly. > > I guess I gave you too much info in one go. A lot of stuff is explained > > there with what kind of steps that can be taken to get rid of > > them:http://hardened.gentoo.org/gnu-stack.xml > > > > You inherited that stuff from gmp, it is a known issue there as well. The > > problem is you have an enormous amount of assembler files so some > > systematic approach is needed. By the way > > > > My comment about yasm is that the fix is also different if you use yasm > > compared to other assembler. In Gentoo gmp has a quite ugly patch that > > get rid of all the problem in one go - on linux only - but wouldn't work > > with yasm. > > I can imagine something like that for the gas files. There aren't so > many yasm files in total, perhaps 50 or so. > > We could give you svn access if you wanted to work on doing this in > MPIR. We would only accept the patch if there were no performance > degradations however. > I will think about your offer when I figure a script/strategy to do it (or find the time). Actually I posted this in the bug for mpir in gentoo bugzilla ( http://bugs.gentoo.org/show_bug.cgi?id=293383 ), may be someone will have an idea over there. For your info mpir 1.2.2 and 1.3.0 are available for Gentoo in the "science" and "sage-on-gentoo" overlays (some special repositories to use debian/ubuntu jargon). > It's very odd to me that assembly code needs to be rewritten to > support this hardware feature. It's certainly something I've never > heard about before. > Assembly is supposed to be "close" to the hardware - it doesn't surprise me at all. The amount of change is rather minimal however. Francois -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org