SHA256 for all Ataris

[mikro]

Doesn't GDB work with GCC compiled binaries for source level debugging, at least under MiNT? (At least old GDB / GCC versions did.)

As Thorsten said, unfortunately the new gcc versions (>= 4.x) suffer from a bug which makes gdb hardly usable. It has something to do with so called 'stabs' format which had been used for a.out targets but as soon as Linux (and others) switched to 'DWARF', nobody has been really maintaining 'stabs' support.

If one has (MiNT) network connection, one might be able to run gdbserver on Atari and GDB GUI, such as DDD on PC:

Yes, that's possible (with the older gcc+gdb combo).

Btw. older GCC versions supported also the old DRI symbol format, which should work with most Atari debuggers. Getting that requires "-Wl,--traditional-format" GCC linker flag.

That still works in newer versions, too.

Btw I have m68k-atari-mint-gcc-2.95 cross compiler in the works (meaning buildable/usable on 64-bit systems) so one could make debug builds with this gcc (as its gdb friendly) and then do the final build with the latest gcc.

[Eero Tamminen]

Doesn't GDB work with GCC compiled binaries for source level debugging, at least under MiNT? (At least old GDB / GCC versions did.)

As Thorsten said, unfortunately the new gcc versions (>= 4.x) suffer from a bug which makes gdb hardly usable. It has something to do with so called 'stabs' format which had been used for a.out targets but as soon as Linux (and others) switched to 'DWARF', nobody has been really maintaining 'stabs' support.
...
Btw I have m68k-atari-mint-gcc-2.95 cross compiler in the works (meaning buildable/usable on 64-bit systems) so one could make debug builds with this gcc (as its gdb friendly) and then do the final build with the latest gcc.

Why not the latest GCC version which output still works with GDB? (Based on your comment, 3.x should still work, as it broke in 4.x)

For assembly level debugging of GCC compiled code, one can use Hatari debugger.

Good luck in trying to do this with gcc compiled code. Some functions you try debug won't even exist because they are inlined.

I've debugged some crashes on Linux from GCC optimized/generated x86 assembly which I understand much less than m68k assembly.

However, that assembly output listed closest preceding symbol name + offset for things like jumps & braches. That made it much easier to read, as one could see where e.g. printf() was called etc.

Such a feature would be nice also for Hatari disassembly output, but currently its debugger relies completely on the CPU core (or separate disassembler) for generating the assembly, and that doesn't currently know anything about symbols loaded by the debugger.

[ThorstenOtto]

I've done a few more checks on this, with the following results:

• The code in the archive i originally posted was a bit broken (so i have removed it, use the version below if you need it). The tests worked, but the file routines failed to do the final update. Simple reason was that i more or less copied your file reading loop, without realizing that your sha256_end did another call to SHA256Acc for the final update.
  
• Your file routines seem to be broken, too. When done reading the file, the bytecount is appended to the stream. Your routine does not check whether that will fit in the buffer, and overwrites the end, and either crashes (because it smashed the stack of the caller), or just produces wrong results. You can test that by running it on a file of 1023 bytes length.
  
• The (relative) poor performance of the C-Version compiled by PureC is mainly due to:
  
  • Although the RORu32 functions is inlined, it is still treated as a normal function call. That means that Pure-C cannot use d0-d2 around this call, and runs out of temporary registers. Replacing the inline function by the generic C Macro however makes things even worse.
    
  • GCC also uses some address registers for temporaries, but Pure-C doesn't
  So in the end, only 4 of the 8 accumulator variables in the inner loop are held in registers.
• The C-Version only does the computation for 1 block (64 bytes), while your assembler version does it for up to 16. Dunno whether that really makes a big difference, since the version compiled by GCC isn't inlined, and still gives good results.
  
• Using -O3 for gcc (for more agressive optimizations) does not give any noticable difference.
  
• Using either gcc 4.6.4 or gcc 8.3 does not give any noticable difference, either.

The new archive now also has versions for SHA224 , SHA1 and SHA512 (just for fun)

Another interesting note: i always thought that MD5 is much simpler than SHA256, and should be much faster. It is, but the difference is smaller than expected (about a factor of 2 or so). Also interesting: on a real 64bit machine SHA512 is about twice as fast as SHA256.