odd, just checked with your same chars pasted into the test app: ------------ jsdf;kljasdf asdf
------------ sun sparc 64 (no change to header) dc0778f4e49bd14622a016e705cbdb15 changed header: 0988915eac85ce5fed09f29252b0cc7f sun sparc 32 bit (no header change) 0988915eac85ce5fed09f29252b0cc7f linux 32 bit adb3013a42bdec7987a807bc750b47d5 linux 32 bit md5sum command on file with only the 2 lines plus the blank line: adb3013a42bdec7987a807bc750b47d5 I would say this askes the question is any md5 value we are getting from other archs valid? what did you get from your alpha for the sum? I guess this needs to be a str array to make sure.. I will write it up. thx. Thanks, Leif > 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 >
