Actually, I was reading some more, and it looks like the standards all mandate that "int" is 32 bit. The confusion is regarding "long" and "long long" where "long" is 32 bit on a 32 bit machine and 64 bit on a 64 bit machine and "long long" is 64 bit on a 32 bit machine and is usually not even defined on 64 bit machines.
When I ported DBMail to Tru64 on Alpha, I had make changes to avoid long long; on Opteron, it's not an issue because of the GNU toolchain and libraries which have standardized these sorts of things. I guess same for Solaris on Sparc. I could also try it out on one of my SGI's. I think that's it for 64 bit machines, though. I have an ancient PA-RISC, but I can't imagine that it's 64 bit. Did I ever mention that I really like old UNIX workstation hardware? This MD5 code was made public domain in 1993. Perhaps at that time it was not uncommon for "int" to be 16 bits, however today it is extremely rare. So I just changed it to always be an unsigned int. Aaron ""Leif Jackson"" <[EMAIL PROTECTED]> said: > well that makes sence. I belive solaris figures out the uint32 as it is > really emulating 32bits on the 64bit kernel. I did some reading and it > seems that dbmail as a whole may not benifit much from accualy being > compiled 64bit, in fact it may make it slower. What is your test showing? > I am glad at least we figured it out. I guess we could agree on some test > data and compile it into testmd5.c instead of using stdin and then we can > make sure the md5 is correct on the diff arch and 64bit vs 32bit? > > -leif > > > > Fixed. Turned out to be quite simple: > > > > In md5.h, find the #ifdef __alpha and change it to this: > > > > #if (defined(__alpha) || defined(__x86_64__)) > > typedef unsigned int uint32; > > #else > > typedef unsigned long uint32; > > #endif > > > > For whatever reason, the Sparc is still using a 32-bit int? Or perhaps it > > is > > not crashing but still giving wrong results? Being a big endian machine, > > there > > is an additional byte order reversing routine that kicks in on the Sparc; > > perhaps the side effect of which is not crashing? Also, clearly, we now > > know > > why my Alpha produced proper results... it was already hacked to work ;-) > > > > The correct way to handle this is with a sizeof test from configure, and > > an > > appropriate entry in config.h to give hints to word-size sensitive code. > > I'll > > make the appropriate changes this weekend :-) > > > > Aaron > > > > > > "Aaron Stone" <[EMAIL PROTECTED]> said: > > > >> Works in 32 bit mode. Also, the resulting md5 is different... > >> > >> There are a couple of compiler warnings in header.c regarding size_t > >> arguments to printf; basically, there's a different size_t size in > >> effect, > >> and of course a different pointer size, too. So either GCC is generating > >> faulty 64-bit code on the Opteron, or there's just a simple > >> 64-bit-unclean > >> portion of the md5 code that isn't generating any warnings but sure is > >> mucking up the output. > >> > >> Aaron > >> > >> > >> [EMAIL PROTECTED]:~/dbmail-2.0rc3> gcc -g -O2 -I . -m32 -o testmd5 > >> testmd5.c *o > >> [EMAIL PROTECTED]:~/dbmail-2.0rc3> file *o testmd5 > >> dbmd5.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not > > stripped > >> debug.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not > > stripped > >> header.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not > > stripped > >> md5.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not > > stripped > >> testmd5: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), > >> dynamically linked (uses shared libs), not stripped > >> [EMAIL PROTECTED]:~/dbmail-2.0rc3> ./testmd5 > >> ;lkajsdf;kljasdf > >> asdf > >> > >> 0a8c8e4fd15849ec600d9aac8e53bf93 > >> [EMAIL PROTECTED]:~/dbmail-2.0rc3> > >> > >> > >> "Leif Jackson" <[EMAIL PROTECTED]> said: > >> > >> > > >> > Humm well it isn't our code that's not 64bit clean, as I emailed in > >> the > >> > previous message, try compiling just thouse objects with -m32 or the > >> equiv > >> > if you can and see what happens. > >> > > >> > -leif > >> > > >> > > Looks like 64 bit by default on the Opteron... > >> > > > >> > > [EMAIL PROTECTED]:~/dbmail-2.0rc3> file *o testmd5 > >> > > dbmd5.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), > >> not > >> > > stripped > >> > > debug.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), > >> not > >> > > stripped > >> > > header.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), > >> not > >> > > stripped > >> > > md5.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), > >> not > >> > > stripped > >> > > testmd5: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), > >> > > dynamically > >> > > linked (uses shared libs), not stripped > >> > > > >> > > > >> > > ""Leif Jackson"" <[EMAIL PROTECTED]> said: > >> > > > >> > >> > Valgrind emulates a Pentium instruction set, so it's not useful > >> on an > >> > >> > x86-64 > >> > >> > processor. They have gdb 5.3 installed, and I just compiled gdb > >> 6.0 > >> > >> for > >> > >> > myself, both of which give me this when I try to read the > >> backtrace: > >> > >> > > >> > >> > >> > >> Make sence on valgrind... hey does the gcc on an operton default to > >> a > >> > >> 64bit linking or do you have to do something like -64 for all the > >> > >> objects? > >> > >> I am thinking about sun and gcc for example where you cannot > >> compile 64 > >> > >> bit without explicity telling the linker to link the 64 bit libs. > >> Just a > >> > >> thought I know sun solaris is totaly diffrent than linux on > >> operton. If > >> > >> it > >> > >> is accessing a 64bit NULL value, but only after completing the > >> output > >> > >> from > >> > >> md5. very odd... I will check this on a sun after compiling 64bit. > >> will > >> > >> let you know in a sec. on sun 32bit it works just find. > >> > >> > >> > >> -leif > >> > >> > >> > >> > >> > >> > [EMAIL PROTECTED]:~/gdb-6.0> ./gdb/gdb > >> > >> > GNU gdb 6.0 > >> > >> > Copyright 2003 Free Software Foundation, Inc. > >> > >> > GDB is free software, covered by the GNU General Public License, > >> and > >> > >> you > >> > >> > are > >> > >> > welcome to change it and/or distribute copies of it under certain > >> > >> > conditions. > >> > >> > Type "show copying" to see the conditions. > >> > >> > There is absolutely no warranty for GDB. Type "show warranty" > >> for > >> > >> > details. > >> > >> > This GDB was configured as "x86_64-unknown-linux-gnu". > >> > >> > (gdb) file ../dbmail-2.0rc3/testmd5 > >> > >> > Reading symbols from ../dbmail-2.0rc3/testmd5...done. > >> > >> > (gdb) run > >> > >> > Starting program: /home/users/s/so/sodabrew/dbmail-2.0rc3/testmd5 > >> > >> > ;lkajsdf;kljasdf > >> > >> > asdf > >> > >> > > >> > >> > b3dd95bad20e039aa898a75cdab51a4d > >> > >> > > >> > >> > Program received signal SIGSEGV, Segmentation fault. > >> > >> > 0x0000000000000000 in ?? () > >> > >> > > >> > >> > > >> > >> > ""Leif Jackson"" <[EMAIL PROTECTED]> said: > >> > >> > > >> > >> >> Aaron, > >> > >> >> > >> > >> >> I would try valgrind, they should have it installed. It does > >> well on > >> > >> >> all > >> > >> >> kinds of bounds checking, as well as memory and cache checks. > >> > >> >> > >> > >> >> -Leif > >> > >> >> > >> > >> >> > > >> > >> >> > Hey, > >> > >> >> > > >> > >> >> > So I whipped up a little wrapper program around read_header() > >> and > >> > >> >> > makemd5() > >> > >> >> > that crashes on the Opteron server at SourceForge, but works > >> > >> properly > >> > >> >> on > >> > >> >> > my > >> > >> >> > Pentium. > >> > >> >> > > >> > >> >> > Just one problem: what tools can I use to debug this thing on > >> > >> >> Opteron!? > >> > >> >> > > >> > >> >> > I've attached my test program. It compiles in the dbmail build > >> > >> tree, > >> > >> >> like > >> > >> >> > so: > >> > >> >> > > >> > >> >> > gcc -g -O -I. -o testmd5 testmd5.c header.o dbmd5.o md5.o > >> debug.o > >> > >> >> > > >> > >> >> > Aaron > >> > >> >> > > >> > >> >> > >> > >> >> _______________________________________________ > >> > >> >> Dbmail-dev mailing list > >> > >> >> [email protected] > >> > >> >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >> > >> >> > >> > >> > > >> > >> > > >> > >> > > >> > >> > -- > >> > >> > > >> > >> > > >> > >> > > >> > >> > _______________________________________________ > >> > >> > Dbmail-dev mailing list > >> > >> > [email protected] > >> > >> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >> > >> > > >> > >> > >> > >> _______________________________________________ > >> > >> Dbmail-dev mailing list > >> > >> [email protected] > >> > >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >> > >> > >> > > > >> > > > >> > > > >> > > -- > >> > > > >> > > > >> > > > >> > > _______________________________________________ > >> > > Dbmail-dev mailing list > >> > > [email protected] > >> > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >> > > > >> > > >> > _______________________________________________ > >> > Dbmail-dev mailing list > >> > [email protected] > >> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >> > > >> > >> > >> > >> -- > >> > >> > >> > >> _______________________________________________ > >> Dbmail-dev mailing list > >> [email protected] > >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >> > > > > > > > > -- > > > > > > > > _______________________________________________ > > Dbmail-dev mailing list > > [email protected] > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
