Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Splitting debugger in two - specific debugger and common GUI
oBFusCATed:
OK, I've finally found some time and here is the modified patch from cbexaminr: http://smrt.is-a-geek.org/codeblocks/patches/dbg/disasm_changes_mine2.patch
What I've done:
1. simplified some comments
2. renamed some variables
3. removed a block #ifdef 0 .... #endif
4. fixed the compilation without pch
If cbexaminr have no objections, the patch could be applied...
Does someone know if it is possible to remove/disable the syntax highlight for particular row?
This feature is needed for the mixed mode disassembly. At the moment all text is highlighted as ASM, which is wrong and ugly.
cbexaminr:
--- Quote from: oBFusCATed on November 23, 2010, 12:27:12 am ---If cbexaminr have no objections, the patch could be applied...
--- End quote ---
One small objection, one additional observation.
objection:
I don't think the logged message about "disasm NO match" should be removed. I think it will be very useful for people who are wondering why an otherwise unnecessary (re-)disassembly occurred.
Might want to change the message slightly if you think it can be more informative, but I believe it will serve a useful purpose - it's a warning about an essentially incorrect response. I think it really shouldn't ever occur, if GDB were always returning the address information in responses.
But, if you want to answer those questions from users, I guess that's OK with me... :)
observation:
disassemblydlg.h seems to have acquired a
#include <vector>
the purpose of which I fail to see...
Sorry I missed those other variables you camel-cased. I really did look for them.
oBFusCATed:
--- Quote from: cbexaminr on November 23, 2010, 05:09:46 pm ---observation:
disassemblydlg.h seems to have acquired a
#include <vector>
the purpose of which I fail to see...
--- End quote ---
4. fixed the compilation without pch (precompiled header)
--- Quote from: cbexaminr on November 23, 2010, 05:09:46 pm ---objection:
I don't think the logged message about "disasm NO match" should be removed. I think it will be very useful for people who are wondering why an otherwise unnecessary (re-)disassembly occurred.
--- End quote ---
Hm, this message looks like it is meant for debugging, not for the users, they won't understand it.
And if I understand the code correctly, the disassembly will be generated, so this is not an error?
cbexaminr:
its an error in that the disassembly should (usually) _not_ have to be re-generated. That code path (I claim) should not have to exist at all if GDB always returned the correct information.
Maybe no one will complain... the code will certainly work without it, its just that when that path is taken you may be re-disassembling the same area repeatedly, which I anticipate somebody will complain about eventually, and it makes it easy to see why the re-disassembly occurred - it marks a path indicating "bad gdb output", so maybe the msg could be "disassembly, bad gdb output". Since I don't know what triggers the instance I've seen, nor how often it or other unrecognized output may occur, tough to say just how often it will occur.
oBFusCATed:
This info is needed for the developer of the plugin and it is there, if someone tries to understand what it is happening he/she will have a clue.
Users don't care for the implementation details...
If you needed this warning message as a user, I'm OK to re-add it, if you needed it only to debug the plugin, I'm against it :)
Lets minimize further talking and get this patch in the tree, OK?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version