From britt at bolen.com Tue Sep 11 16:09:08 2007 From: britt at bolen.com (Britt Bolen) Date: Tue, 11 Sep 2007 10:09:08 -0400 Subject: compilation errors on iPhone Message-ID: <55bc0b200709110709o51a3347ejb3821796bdf06b89@mail.gmail.com> I'm trying to build libgcrypt so that I can build vpnc on the iphone, but I'm running into a compilation/assembly error that I've not been able to solve. /usr/local/arm-apple-darwin/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../src -I/usr/local/arm-apple-darwin/include -g -O2 -Wall -MT mpih-div.lo -MD -MP -MF .deps/mpih-div.Tpo -c mpih-div.c -fno-common -DPIC -o .libs/mpih-div.o Bad $ operand number in inline asm string: '${:@} Inlined umul_ppmm umull ${1:r}, ${0:r}, ${2:r}, ${3:r}' make[2]: *** [mpih-div.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 The iPhone is an arm processor, though I wasn't able to figure out how mpih-dev.c got the correct #defines to figure out which assembly macro was actually being called... anyhow, I was hoping to get some suggestions on workarounds or solutions so I can get this built. config.log : http://eludicate.com/~bolen/tmp/gcrypt_iphone/config.log thanks, B From wk at gnupg.org Wed Sep 12 22:41:02 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 12 Sep 2007 22:41:02 +0200 Subject: compilation errors on iPhone In-Reply-To: <55bc0b200709110709o51a3347ejb3821796bdf06b89@mail.gmail.com> (Britt Bolen's message of "Tue, 11 Sep 2007 10:09:08 -0400") References: <55bc0b200709110709o51a3347ejb3821796bdf06b89@mail.gmail.com> Message-ID: <87d4wn8vmp.fsf@wheatstone.g10code.de> On Tue, 11 Sep 2007 16:09, britt at bolen.com said: > Bad $ operand number in inline asm string: '${:@} Inlined umul_ppmm > umull ${1:r}, ${0:r}, ${2:r}, ${3:r}' My guess is that the problem is in mpi/longlong.h > The iPhone is an arm processor, though I wasn't able to figure out how > mpih-dev.c got the correct #defines to figure out which assembly macro mpi/config.links is the script run from configure which figures out these details and creates some macros. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From tg at swox.com Fri Sep 21 15:42:35 2007 From: tg at swox.com (Torbjorn Granlund) Date: Fri, 21 Sep 2007 15:42:35 +0200 Subject: gcrypt, MPI, GMP and powerpc64 Message-ID: <86lkb0jfsk.fsf@king.swox.se> [I found an old message in the archives, from July 2006, that I'd like to comment.] > - Would it possible to use GMP in gcrypt? No. For security reasons we don't wnat the whole GMP suff. Just the modified and meanwhile hopefuly well security audited libgcrypt code. Of course, not using "the whole GMP suff" doesn't mean one needs to rip out the code one wants to use. That's the wonderful thing with libraries. > - Why using MPI instead of GMP? At the time I wrote GnuPG (1997) GMP development had stalled for years and was stuck at 2.something. There had been 3 releases (2.0 through 2.0.2) in the year before 1997. GMP 2.0 was the biggest ever change of GMP ever. How many releaases per year would you want not to consider a project as "stalled"? There was no maintainer for years. That is simply not true. I have been maintainer since the first release, without any interruption. Only later GMP 3 started and changed a lot of the assembler stuff - I have seen eports that GMP is far less portable than it used to be. I cannot question if you have "seen reports" about this and that, but GMP is about as portable as it has always been. It is a shame that you seem to have based your decision only on false information. There are quite some heavy changes in the internal working and what we actually only need are the low level fucntions - should be easy to adjust to libgcrypt but it is more work than I can spend on it. So now GMP changed too much? Either it is stalled, or it moves to rapidly. :-) We also need better optimized code for modern ia32 CPUS as well as for ia64 or AMD. If you have some specific optimization ideas for "modern ia32 CPUS", I'd like to hear about them. People often makes such claims, but they never seem to be able to get down to details of the optimization they have in mind. (Granted, the x86_64 code in GMP is far from optimal.) -- Torbj?rn From wk at gnupg.org Mon Sep 24 09:44:54 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Sep 2007 09:44:54 +0200 Subject: gcrypt, MPI, GMP and powerpc64 In-Reply-To: <86lkb0jfsk.fsf@king.swox.se> (Torbjorn Granlund's message of "Fri, 21 Sep 2007 15:42:35 +0200") References: <86lkb0jfsk.fsf@king.swox.se> Message-ID: <871wco5wy1.fsf@wheatstone.g10code.de> On Fri, 21 Sep 2007 15:42, tg at swox.com said: > Of course, not using "the whole GMP suff" doesn't mean one needs to > rip out the code one wants to use. That's the wonderful thing with > libraries. It is a matter of code auditing. We don't want to have unused code in a security critical application. Even if not used it increases complexity and requires an autitor to look at the unused code. > There had been 3 releases (2.0 through 2.0.2) in the year before 1997. > GMP 2.0 was the biggest ever change of GMP ever. How many releaases > per year would you want not to consider a project as "stalled"? That is 10 years ago and I don't have my mail archives of that time anymore online. gmp 2.0.2 is from June 1996. I am pretty sure that I wrote to bug-gmp at prep.ai.mit.edu and to you (at the address given in the ChangeLog). The only reply I can remember (whether at this time or only later) is to wait for GMP 3 which was released in April 2000. Yes, I call this stalled. > That is simply not true. I have been maintainer since the first > release, without any interruption. Comments in the ssh included gmp also indicated that there was no active maintenance at that time. Quite some bugs in the configure scripts and longlong.h had been fixed in Debian and not by you. > It is a shame that you seem to have based your decision only on false > information. "Based on no information" wpuld express that better. Anyway, there are enough other reasons not to use GMP for GnuPG. When eventually GMP 3 was released I was a bit disappointed that the entire configuration system changed in a way which makes it very hard to port the code to libgcrypt/gnupg but well that is my reponsibility. >> So now GMP changed too much? Either it is stalled, or it moves to > rapidly. :-) I am talking about the years 1997 to 2000. > I'd like to hear about them. People often makes such claims, but they > never seem to be able to get down to details of the optimization they > have in mind. (Granted, the x86_64 code in GMP is far from optimal.) Meanwhile Werner Dittmann contributed faster X86_64 code. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From tg at swox.com Mon Sep 24 16:07:07 2007 From: tg at swox.com (Torbjorn Granlund) Date: Mon, 24 Sep 2007 16:07:07 +0200 Subject: gcrypt, MPI, GMP and powerpc64 In-Reply-To: <871wco5wy1.fsf@wheatstone.g10code.de> (Werner Koch's message of "Mon\, 24 Sep 2007 09\:44\:54 +0200") References: <86lkb0jfsk.fsf@king.swox.se> <871wco5wy1.fsf@wheatstone.g10code.de> Message-ID: <86zlzci2d0.fsf@king.swox.se> Werner Koch writes: It is a matter of code auditing. We don't want to have unused code in a security critical application. Even if not used it increases complexity and requires an auditor to look at the unused code. OK, but then you have a wonderful tool called ar. It can extract what you need. > That is simply not true. I have been maintainer since the first > release, without any interruption. Comments in the ssh included gmp also indicated that there was no active maintenance at that time. Quite some bugs in the configure scripts and longlong.h had been fixed in Debian and not by you. I cannot comment about Debian's local changes to any package, since I don't follow them. But if you're judging local changes in any GNU/Linux or BSD system is an indicator on whether a package is maintained or not, then I suppose all and every package is unmaintained. > It is a shame that you seem to have based your decision only on false > information. "Based on no information" would express that better. Anyway, there are enough other reasons not to use GMP for GnuPG. The NIH factor is usually the most important one in situation such as this. Even if people very rarely would confess that to be a factor. Writing your own bignum code will almost surely introduce more security related bugs than using a well-tested library. Do you BTW completely avoid the C library too? When eventually GMP 3 was released I was a bit disappointed that the entire configuration system changed in a way which makes it very hard to port the code to libgcrypt/gnupg but well that is my responsibility. You're paying for the NIH stuff. If you had made the right decision, and used the GMP low-level interfaces just as they are, then you'd been much better off. >> So now GMP changed too much? Either it is stalled, or it moves to > rapidly. :-) I am talking about the years 1997 to 2000. Do I understand you correctly that the decisions you made in 1997 were based on what happened in the years 1997 to 2000? > I'd like to hear about them. People often makes such claims, but they > never seem to be able to get down to details of the optimization they > have in mind. (Granted, the x86_64 code in GMP is far from optimal.) Meanwhile Werner Dittmann contributed faster X86_64 code. Alright! But what about your claims about x86 32-bit code? Show us your hidden tricks! Let me again quote your statement from last year: "We also need better optimized code for modern ia32 CPUS [than in GMP] ..." -- Torbj?rn From wk at gnupg.org Mon Sep 24 18:49:55 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Sep 2007 18:49:55 +0200 Subject: gcrypt, MPI, GMP and powerpc64 In-Reply-To: <86zlzci2d0.fsf@king.swox.se> (Torbjorn Granlund's message of "Mon, 24 Sep 2007 16:07:07 +0200") References: <86lkb0jfsk.fsf@king.swox.se> <871wco5wy1.fsf@wheatstone.g10code.de> <86zlzci2d0.fsf@king.swox.se> Message-ID: <87bqbsypn0.fsf@wheatstone.g10code.de> On Mon, 24 Sep 2007 16:07, tg at swox.com said: > OK, but then you have a wonderful tool called ar. It can extract what > you need. I am talking about source and not about object files. > don't follow them. But if you're judging local changes in any GNU/Linux > or BSD system is an indicator on whether a package is maintained or not, > then I suppose all and every package is unmaintained. I don't understand why you insist after 10 years that at that time the package was maintained. > The NIH factor is usually the most important one in situation such as > this. Even if people very rarely would confess that to be a factor. A requested design goal for GnuPG was to avoid storing any sensible data in pageable memory. Thus most of the alloca's had to be replaced by custiomized malloc functions. For a general number crunching application this is not needed and to be avoided due to some overhead. > Writing your own bignum code will almost surely introduce more > security related bugs than using a well-tested library. Do you BTW Please check the code and you will noticed that it is a stripped down GMP 2.0.2. > You're paying for the NIH stuff. If you had made the right decision, > and used the GMP low-level interfaces just as they are, then you'd been > much better off. See above. > I am talking about the years 1997 to 2000. > > Do I understand you correctly that the decisions you made in 1997 were > based on what happened in the years 1997 to 2000? Sorry, I can't parse that. I simply mentioned that there was no visible development in GMP between June 1996 and April 2000. I started with GnuPG in fall 1997. > Alright! But what about your claims about x86 32-bit code? Show us > your hidden tricks! Let me again quote your statement from last year: > "We also need better optimized code for modern ia32 CPUS [than in GMP] I am not anymore a machine code expert. However SSE etc are clearly things you want for crypto operations. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From tg at swox.com Mon Sep 24 19:25:41 2007 From: tg at swox.com (Torbjorn Granlund) Date: Mon, 24 Sep 2007 19:25:41 +0200 Subject: gcrypt, MPI, GMP and powerpc64 In-Reply-To: <87bqbsypn0.fsf@wheatstone.g10code.de> (Werner Koch's message of "Mon\, 24 Sep 2007 18\:49\:55 +0200") References: <86lkb0jfsk.fsf@king.swox.se> <871wco5wy1.fsf@wheatstone.g10code.de> <86zlzci2d0.fsf@king.swox.se> <87bqbsypn0.fsf@wheatstone.g10code.de> Message-ID: <86k5qght62.fsf@king.swox.se> Werner Koch writes: > don't follow them. But if you're judging local changes in any GNU/Linux > or BSD system is an indicator on whether a package is maintained or not, > then I suppose all and every package is unmaintained. I don't understand why you insist after 10 years that at that time the package was maintained. Because it was. Look at the ChangeLog file in any GMP release, and you'll see that GMP has been developed at a good pace during all the years. Not sure how you define "maintained", but it was provably developed, and the mailing lists were being responed to. > The NIH factor is usually the most important one in situation such as > this. Even if people very rarely would confess that to be a factor. A requested design goal for GnuPG was to avoid storing any sensible data in pageable memory. Thus most of the alloca's had to be replaced by custiomized malloc functions. For a general number crunching application this is not needed and to be avoided due to some overhead. Custom allocation has been possible since GMP 1. The TMP_ALLOC stuff that defaults to using alloca, can trivially (at configure time) be made to use the customized allocation. > Alright! But what about your claims about x86 32-bit code? Show us > your hidden tricks! Let me again quote your statement from last year: > "We also need better optimized code for modern ia32 CPUS [than in GMP] I am not anymore a machine code expert. However SSE etc are clearly things you want for crypto operations. Ah, did you guess that GMP does not use SSE, and then based on that guess spread the rumor that the GMP x86 code isn't very good? GMP uses SSE, of course. We've all seen FUD about GNU projects on the Net many times, but I am astonished that a lead developer of one GNU project spreads FUD about another GNU project. -- Torbj?rn From wk at gnupg.org Thu Sep 27 15:25:18 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 27 Sep 2007 15:25:18 +0200 Subject: gcrypt, MPI, GMP and powerpc64 In-Reply-To: <86k5qght62.fsf@king.swox.se> (Torbjorn Granlund's message of "Mon, 24 Sep 2007 19:25:41 +0200") References: <86lkb0jfsk.fsf@king.swox.se> <871wco5wy1.fsf@wheatstone.g10code.de> <86zlzci2d0.fsf@king.swox.se> <87bqbsypn0.fsf@wheatstone.g10code.de> <86k5qght62.fsf@king.swox.se> Message-ID: <87ejgkme9t.fsf@wheatstone.g10code.de> On Mon, 24 Sep 2007 19:25, tg at swox.com said: > years. Not sure how you define "maintained", but it was provably > developed, and the mailing lists were being responed to. Well, okay. But the fact was not widely known and the 3.0 release appeared more or less out of the nowhere. > Custom allocation has been possible since GMP 1. The TMP_ALLOC stuff > that defaults to using alloca, can trivially (at configure time) be > made to use the customized allocation. Not possible. The lockable memory is very limited and thus it was not that somple. Please check the code to see what I did to keep the amount of locked memory at a minimum. > Ah, did you guess that GMP does not use SSE, and then based on that > guess spread the rumor that the GMP x86 code isn't very good? I know x86 well enough to check whether SSE is used or not. > GMP uses SSE, of course. 2.0.2 does not. Or what file did I missed? > We've all seen FUD about GNU projects on the Net many times, but I am > astonished that a lead developer of one GNU project spreads FUD about > another GNU project. I never complained about current versions of GMP and 2.0.2 was very fine code at its time. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.