Re: What I expect on Update3
Posted: Thu Jul 07, 2011 10:48 pm
Nice readHans-Joerg Frieden wrote:The reason why a lot of crashes end up in a deadlock is known to us and is something we'll be looking at.
Support Forum
https://forum.hyperion-entertainment.com/
https://forum.hyperion-entertainment.com/viewtopic.php?f=14&t=155
Nice readHans-Joerg Frieden wrote:The reason why a lot of crashes end up in a deadlock is known to us and is something we'll be looking at.
I already tried many times to explain that to Mrodfr but he does not seem to understand.Hans-Joerg Frieden wrote: gdb and addr2line are developer tools, and completely useless if the binary doesn't contain debug info (which is true for almost any released software), so adding them to anything but the SDK isn't really making much sense
We have a half-finished draft for a new library to help debugging stuff (basically, a debugger in a shared library) that would be possible to integrate into Grim Reaper. Unfortunately, the actual implementation won't start for some time due to workload and time constraints.abalaban wrote:However for executable with debug info having addr2line integrated into GrimReaper would be a great gain of time, but I suspect addr2line only works with programs generated by GCC build chain, doesn't it ?
Just small note which will make not big sense, but : gdb still can be helpfull even if binary not have debug info. I.e. if programmer just briefly know assembler, he still can (even without debug info), check where on assembler instructions crash happens, and if it store registers he will think in one way, if it load registers, he will think about others. Or even maybe he will see that crash happens in "prologue" function, so he will think about other. And i just do not remember from top of head more examples, but only know that even without debug gdb can be helpfull. Its has so many features (like dumping of hex-data by address, disassebling of need it area, and so on) , that even without debug info it still very good to have. So maybe have it in the main os4 release can make a sense (at last GR have button to attach to GDB). But not big deal of course, any sane programmer install SDK always..gdb and addr2line are developer tools, and completely useless if the binary doesn't contain debug info
Can you say more about ? Did it something done from scratch, or based on GDB sources ? Maybe you even can release it without integration to GR, just with some small API set, so 3d party developers can just make a gui for. What current library can do ? (and what you still want to implement) ?We have a half-finished draft for a new library to help debugging stuff (basically, a debugger in a shared library)
That's good news for sure. I hope you'll find some time to implement this. Better development tools are always a good thingThomas Frieden wrote:We have a half-finished draft for a new library to help debugging stuff (basically, a debugger in a shared library) that would be possible to integrate into Grim Reaper. Unfortunately, the actual implementation won't start for some time due to workload and time constraints.
I haven't tested 68k programs since 1.5 years. Programs tested here are mainly Linux ported to AOS4 program (comand line program) or allready AOS4 program in new beta version.I already tried many times to explain that to Mrodfr but he does not seem to understand.
Moreover as a programmer current debug outputs are sufficient to make me spot the problem in general. The problem is that Mrodfr often beta-tests 68k softwares or 68k crosscompiled ones, meaning that developers he's sending his output does not know what a GrimReaper log is or how to use it (for this last I feel like it's more a matter of laziness or even in some cases bad faith (not sure of this expression in english).
And mainly it's because the programmer is cross-compiling for AOS4, does not own an AOS4 capable machine and does not care so much about it. Anyway as afxgroup said above if the program is compiled with correct GCC debug command-line and not stripped, you can always spot the line were the crash comes from. Somethimes the crash is in a system function but then you only have to backtrack to latest programmer's line and you have the guilty line (in such case it's often due to bad parameters).Mrodfr wrote:I haven't tested 68k programs since 1.5 years. Programs tested here are mainly Linux ported to AOS4 program (comand line program) or allready AOS4 program in new beta version.
Unfortunately, even with the DSI, the programmer sometime failed to found where the problem are located on the sourcecode.