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 > --
