Code::Blocks
Developer forums (C::B DEVELOPMENT STRICTLY!) => Plugins development => Topic started by: Ceniza on January 10, 2006, 08:37:35 am
-
I must admit I don't use debuggers that much but, when I do, getting a good interface helps a lot.
There's a *nix front-end for GDB (and some other debuggers) called DDD. The only way to get it working on Windows is thru Cygwin + X for Cygwin, but it won't work as good as on a *nix OS.
The GUI library used is awful (well, it's Motif but it looks awful), but it has a pretty nice watches window/widget.
Take a look:
(http://www.gnu.org/software/ddd/all.png)
Pretty nice, even more when you're dealing with pointers.
Someone could find this useful too:
(http://www.gnu.org/software/ddd/plots.png)
Now you have seen how far a debugger front-end can go, could you imagine Code::Blocks with something like that (of course, with the nice interface of Code::Blocks :))?
First step: the widget.
Ideas, suggestions, objections, VOLUNTEERS?
(I just wanted to show you that, I have my doubts about implementing it :P)
-
Really interesting :D. Dammage that to work under Windows it needs Cygwin :(.
IMHO, It would be a useful addition to C::B.
Michael
-
ddd (data display debuger) is by far the best frontend to gdb. When you get past it's interface you can do anything that is possible with gdb. The main thing here is that it's a dedicated application that only does one thing for many many years and does it good - being a gdb frontend. I don't think that it would be possible to get the features of ddd on codeblocks (it would require the whole team to get involved with just that).
Of course since I heavily use ddd I'd like to see something like that in c::b
-
AFAIK, wxWidgets has some plotting functions. But I think that before considering writing a graphical front-end, we would have to do something similar with text-only. Or at least have an object framework for representing the data.
-
Ideas, suggestions, objections, VOLUNTEERS?
I see no reason for graphical gizmos in a debugger. Really, what do you need that for?
-
At the risk of sounding extremely stupid or ignorant... what data produced by a debugger makes sense to be displayed in a 3D area plot?
-
I would use the graphical displays. I do a lot with Finite Elements / other numerical methods, and very often my programming mistakes come from certain elements being skipped or computed twice, etc. With a graphical tool to look at my data it would be easy to spot if a certain data-point is never changing or NaN or whatever.
Jonathan
-
I see no reason for graphical gizmos in a debugger. Really, what do you need that for?
It isn't a need, I just like to "visualize" things better, and it seems I'mn't alone :)
At the risk of sounding extremely stupid or ignorant... what data produced by a debugger makes sense to be displayed in a 3D area plot?
At least for lonesock it makes sense. I just wanted to show another image of what DDD can do. Not like I'm going to use it by now :)
I was looking for a wx widget which could help in the implementation but found nothing.
There's still a lot of work to do, bugs to squash and more in the way to consider this at least "average priority", but who knows, this little thingy could become true (Code::Blocks 7.0 maybe?) :)
-
I was looking for a wx widget which could help in the implementation but found nothing.
wxGLCanvas
-
wxGLCanvas? I mean the watches one, not the 3D one. Something able to draw boxes with text, arrows, and such, similar to Graphviz.
-
Is OGL (in wxWidgets contrib) not exactly what you want? I've never used it, but I guess that's what you need.
-
I don't really think OGL is what I want/need :)
-
But it says "draw lines, shapes, and connectors"... :)
EDIT:
Hey, wait a minute... why don't you write out SVG to a string buffer? Then you can feed that to a SVG renderer, there are a few for wxWidgets. That way, it's scaleable and printable, too, for free :)
-
thomas: have you tried DDD? :)
With SVG we could make a nice looking drawing, but... I still think you're considering a widget for the plots while I'm considering a widget for the watches.
The widget is needed to implement the drawings in the first image, the one with the list.
-
The widget is needed to implement the drawings in the first image, the one with the list.
Yes, SVG is just fine for that. Make a big SVG canvas and give it a document which has a box here, an arrow there, and some text. Should work really nicely, and you can use all of the SVG candy like rounded boxes and transparency or gradients if you like.
-
I see no reason for graphical gizmos in a debugger. Really, what do you need that for?
It isn't a need, I just like to "visualize" things better, and it seems I'mn't alone :)
No you are not alone :). I think it is important (at least for me :)) to provide a clear, easy-to-understand, scalable view of the debugger info.
(Code::Blocks 7.0 maybe?) :)
C::B 7.0? :D
Michael
-
Hi, I'm opening this old topic because I would like to implement some functionality of DDD to Code::Blocks. As I noticed, new features to debugger are added by editing the code in plugins/debuggergdb/ directory. But I try add new functionality by pure new plugin. This is my test code:
void DDDLikeWatches::OnAttach()
{
cbDebuggerPlugin *debugger = reinterpret_cast<cbDebuggerPlugin *>(
Manager::Get()->GetPluginManager()->FindPluginByName(wxT("Debugger"))
);
DebuggerGDB *gdb = reinterpret_cast<DebuggerGDB *>(debugger);
DebuggerDriver *driver = gdb->GetState().GetDriver();
}When I try compile this, I get undefined reference to `DebuggerState::GetDriver()'. My question is: Where is the problem? Can I access debugger's functions from debugger.dll from other plugin or must modify original debugger plugin's code to add this functionality to debugger? I link debugger.dll to my project.
-
Where is the problem? Can I access debugger's functions from debugger.dll from other plugin or must modify original debugger plugin's code to add this functionality to debugger? I link debugger.dll to my project.
You should link against the SDK, not the plugin. BTW: If you are working on the debugger, make sure you are using the debugger branch as:
1.) Your features might already have been implemented there
2.) We will sooner or later switch to this branch, so your changes to trunk might be very hard to integrate later.
-
Thanks for your reply. I'm linking against SDK too (codeblocks.dll).
1.) Feature that I try implement is Graphical Inspection of Data Structures and viewing them like oriented graphs. This feature isn't implemented there.
2.) As I noticed in SVN: debugger_branch: merged with trunk (trunk to debugger_branch)
So I use trunk.
Because, I don't know how to link debugger's functions, I'll try edit original sources to add this functionality.
-
2.) As I noticed in SVN: debugger_branch: merged with trunk (trunk to debugger_branch)
So I use trunk.
Please read carefully, it's written there: trunk to debugger_branch. Thus, features implemented in trunk not yet in the debugger branch have been merged. Still it will always be as : debugger branch = trunk + debugger related modifications. Thats what the branch is for, it has a way different (re-factored) implementation of th debugger.
Once the debugger branch comes merged into trunk, there won't be a need for this branch anymore and it'll be closed. For now, all debugger related development is there and only there.
-
m.29:
Probably you need to modify the sdk and put most of the drawing code and data structures there.
If you do so all plugins can implement this graphical mode, not only the current one and there will be minimal code duplication.
See how it is done for the other features (watches, breakpoints, etc).
-
Thanks for your replies and sorry for my inattention. I use debugger_branch (/branches/wxpropgrid_debugger/) now.
I'm still implementing this feature to C::B and have one question. I try to add functionality that after double click on pointer element in structure dereferences pointer and join nodes of graph by edge. Here is relevant part of my event handler for that:cbDebuggerPlugin* debugger = Manager::Get()->GetDebuggerManager()->GetActiveDebugger();
wxString watchString; watch->GetFullWatchString(watchString);
watch = debugger->AddWatch(wxT("(*") + watchString + wxT(')'));
if(!watch) { return; }
ViewNode* node = new ViewNode(
this->GetParent(),
watch,
this->GetPosition() + wxPoint(this->GetSize().GetWidth() + 20, 0) // TODO (m.29##): automatic graph layouts
);
this->GetParent()->AddChild(node);
ViewNode::JoinNodes(this, node);But in ViewNode's constructor I get uninitialized watch (e.g. watch->GetChildCount() == 0 if watch is structure type). I know it is because watch is parsed in parallel to my code. I don't know how to wait for end of parsing. Or how can I find out that watch was parsed yet? I tried find answer in C::B codes but it seems nothing special is done after calling cbDebuggerPlugin::AddWatch() there.
-
When watches are updated WatchesDlg::UpdateWatches() is called
-
Thanks, it helps. I'm implementing "index out of bounds" checking now. I noticed some things during exploring C::B sources:
1) Function ParseCDBWatchValue has some strange (for me) condition if (tokens[0] == wxT("class") || tokens[0] == wxT("class"))I think it should be if (tokens[0] == wxT("struct") || tokens[0] == wxT("class")) as it is a few rows below.
2) I edited GDBWatch::GetFullWatchString function 'cause for arrays it always gave me ArrayName.[index].
3) Because I would like to check indexing out of bounds I added size to array watches in GdbCmd_Watch class.
4) In GdbCmd_FindWatchType class there was "whatis &" instead of "whatis " string used to finding type of watch and then tmp.substr(0, tmp.length() - 1); used to removing last "*". But this was bad for arrays or functions:
- int (*)[4] -> int (*)[4
- int (*)(int) -> int (*)(int
- ...
I made the patch (http://dl.dropbox.com/u/22120595/array_dbg001.patch) for this things, but if I done something wrong someone explain me what and why, please.
-
1. Have you tried it with real CDB and can you provide a test case (see debuggergdb_test_parser.cpp)
2. This seems unused in current code, so it was not tested
3. SetArray and SetArrayParams are called by the GUI, so set the properties of the watch, then this properties are used to execute the correct commands.
So your usage is wrong, because you'll override the choice made by the user (probably you need to add more members).
Also GetFullWatchString should not call contains, but use some member to check if the symbol is array.
4. This is a workaround for a problem in GDB -> "const wxString &" passed as parameter was not watchable...
But the main problem is that I don't get the whole picture, why you need this changes.
'index out of bounds checking' means nothing to me.
Can you explain in more details, please?
-
1) I didn't test it, but that condition is really weird. Why there is test for the same thing twice? Here is the test case:
TEST(CDBSingleLineStructPointer)
{
GDBWatch w(wxT("t"));
CHECK(ParseCDBWatchValue(w, wxT("struct t * 0x123456"));
CHECK_EQUAL(wxT("t*=0x123456"), w);
}
TEST(CDBSingleLineClassPointer)
{
GDBWatch w(wxT("t"));
CHECK(ParseCDBWatchValue(w, wxT("class t * 0x123456"));
CHECK_EQUAL(wxT("t*=0x123456"), w);
}
2) In my code there is functionality that dereferences pointer (http://dl.dropbox.com/u/22120595/array_of_structs_deref.png) on double click on variable. There is array of structures struct s {
payload_t payload;
struct s* next;
} item1, item2, ...;
struct s array[] = {
item1,
item2,
...
};Then I try dereference pointer next in structure on index 0 I get (*array.[0].next) instead of (*array[0].next). This expression is not valid and gdb can't return right result.
3) I don't override user's choice because there is a condition that allows set parameters only 1st time. If my code overrides user's choice there is watch->SetArray(true); what also overrides user's choice. But no. As I tested if I change properties of watch everything stay set according to my new choice. Only if watch format is Undefined and it is array with size (int array[29];) but GDBWatch::IsArray returns false everything is set to default. I hope it is understandable - my English and speech aren't good :-(
I changed GDBWatch::GetFullWatchString into test if parent is array - hope it's OK now.
4) For me it is good. Can you provide some example when it is not watchable? Or it is issue of any specific platform?
I graphical representation of watches programmer can see actual indexed item of array in bold (http://dl.dropbox.com/u/22120595/array_autoindexing.png). My idea is, if i know index and size of array I can check if index is not bigger than size of array. Then C::B warns programmer about it. There is some complications now and I want to do on automatic graph layout of oriented graphs so I return to this later, but I think is not good if size of array will be available anyway.
In my code, there is many changes, but these seem to be bugs and useful changes that affect functionality of C::B. But I want to find out if some of them is not intention (like "whatis &" issue) because there is no explanation in comments. That's why I put them here.
-
Can you provide a complete patch of your progress?
Probably we can integrate some parts of it already.
The least we can do is to stop you from doing wrong things/designs at the beginning...
p.s. I'll answer to you questions in tonight, no time now.
-
Hmm, I don't want to provide my complete work, because it is my school project and I don't know if I won't violate some of school rules. But I'll ask my supervisor if it will be problem. I certainly want to provide my work after my project will be finished.
-
Reply to the previous post:
1. Not a real test, run it through CDB or you should wait for me find time to run it myself. :lol:
2. Looks good :) (except for the scrollbars), but auto dereferencing in current plugin is hard (many special cases will be broken)
3. If it works, OK, I'll give it a try...
4. Debugging C::B under linux. With older gdb's this was a problem. Probably I should remove the hack and see if it works correctly, with 7.2+ ...
This index out of bounds is pretty much uses, because most of the time (in real world code) you get bare pointers not arrays. If I were you I wouldn't bother with this feature too much, because it has very little value.
p.s. Please test you patch on a modern linux machine (64bit if possible). The sooner you do it the better :)
p.p.s. You can send me the patch on e-mail, so it will stay private, but you'll get some feedback on it.
-
1) I don't like waiting and I did some test (http://dl.dropbox.com/u/22120595/main.cpp). Here is relevant screen (http://dl.dropbox.com/u/22120595/cdb_struct_test.jpg). As you can see from log, structure type would be HWND__* and value 0x0000000. But it is wrong in the watches window. For similar class is everything fine.
2) Auto derefencing isn't my aim so far. Only user dereferences pointers by double click. I don't how to hide scrollbars and set size of wxTreeCtrl according to visible children :-( I want concentrate on functionality so I lay aside by now but I'm asking in the appropriate forum for it.
4) Yes, I try it on Linux with gdb 7.1 and it really doesn't work. But with some RE it would be correct on function and array. I try something.
But I plan to add functionality that allows assign variable to array. Variable that store the array size. If there is realloc in program, it would be good to assign variable storing the size of array and this array will have correct size whole time. Now I must every time change size in context menu according to new reallocated size. In my school C::B is used as additional teaching aid and this could be good for beginners but not only for them.
I tried my patch on Ubuntu 10.04 LTS (64bit) but it crashed down. Even clean svn checkout. I only open codeblocks-unix project, compile and after ./update run. Code::Blocks crashed immediately. I'll try find out why.
My supervisor allows me to publish sources so after some changes I can provide it. Thanks for your help :-)
-
But I plan to add functionality that allows assign variable to array. Variable that store the array size. If there is realloc in program, it would be good to assign variable storing the size of array and this array will have correct size whole time. Now I must every time change size in context menu according to new reallocated size. In my school C::B is used as additional teaching aid and this could be good for beginners but not only for them.
I'm not sure I understand what you are talking about, but it sounds like something uses, at least in the C++ world.
Also this seems like a task for the real debugger (GDB/CDB), not the debugger front end (C::B).
Edit: uses, should have been useless... :(
-
1) I don't like waiting and I did some test (http://dl.dropbox.com/u/22120595/main.cpp). Here is relevant screen (http://dl.dropbox.com/u/22120595/cdb_struct_test.jpg). As you can see from log, structure type would be HWND__* and value 0x0000000. But it is wrong in the watches window. For similar class is everything fine.
In SVN, with some modifications to the tests (you've not run them!) :lol:
-
3. If it works, OK, I'll give it a try...
Still broken here :(
> whatis output
Attempt to take contents of a non-pointer value.
>>>>>>cb_gdb:
> output output
(const wxString &) @0x7fffffffb5f0: {
<wxStringBase> = {
m_pchData = 0x1ef5e18 L"Reading symbols from /home/obfuscated/projects/tests/_cb_cc/call_tip/bin/debug/call_tip...done."
}, <No data fields>}>>>>>>cb_gdb:
Put a breakpoint in GDB_Driver::ParseOutput and add the parameter output in the watches...
-
4) In GdbCmd_FindWatchType class there was "whatis &" instead of "whatis " string used to finding type of watch and then tmp.substr(0, tmp.length() - 1); used to removing last "*". But this was bad for arrays or functions:
- int (*)[4] -> int (*)[4
- int (*)(int) -> int (*)(int
- ...
This should be fixed in svn, can you test it?
-
Pointers on structures in CDB is good now. But tests in debuggergdb_test_parser_cdb.cpp are wrong. Results would be t*=0x123456 instead of t=0x123456, because of inputs are pointers.
GdbCmd_FindWatchType gives correct types. Thanks. I wrote different patch for it. Next time I will faster :)
I'm not sure I understand what you are talking about, but it sounds like something useless, at least in the C++ world.
Also this seems like a task for the real debugger (GDB/CDB), not the debugger front end (C::B).
Yes, it's really task for GDB and GDB supports it. It is called Array slices (http://www.gnu.org/software/ddd/manual/html_mono/ddd.html#Array%20Slices). I tried to find similar functionality in CDB debugger, but I think it is not implemented there.
Sorry for my late answers - I was busy by my another school projects.
-
Pointers on structures in CDB is good now. But tests in debuggergdb_test_parser_cdb.cpp are wrong. Results would be t*=0x123456 instead of t=0x123456, because of inputs are pointers.
No, the test are correct, but the parser is broken if it returns t*=0x123456.
The tests work correctly on linux. I've not tried them on windows, probably I must do so in the next couple of days.
-
Sorry, I changed GetSymbol with GetType. I tried it on Ubuntu, and it works correctly.
I resolved all collisions in my sources and created patch (http://dl.dropbox.com/u/22120595/visualwatches0001.patch). Every feedback will be appreciated. Thanks for your time :D
-
Why do you have GUI code in the plugin?
And why do you need AddVisualObject and DeleteVisualObject (probably because of the previous :) )?
Probably a better way is to use watches directly, so then your implementation will be common for all debugger plugins.
At the moment every plugin should reimplement your tree controls in order to implement this feature.
You should modify the watches, to mark them non visible in the Watches windows, but I think this is minor problem at the moment.
For testing purposes you can have them duplicated in both windows (Watches window and your new window).
p.s. For doing GUI the official way is through the use of wxSmith.
p.p.s. I was thinking if it would be possible to implement this whole visible debugging as a separate plugin, so its impact on C::B is minimal. What do you think?
-
Hmm, because I have to display data structures? :? What other way is possible to display them? Or what is it wrong specifically?
Every plugin can implement this methods (AddVisualObject and DeleteVisualObject), and then create your own visual representation of watch. This representation will be created then by calling this method.
My idea was, that every plugin can implement your own representation of watch, which will be displayed on the canvas. My representation is tree control, but some other plugin can implement it other way.
This is great idea. I can try it :) But what is major problem then?
ad p.s. I tried to do things similar to nearest code. I read articles about formatting and other advices in C::B, but I saw that every piece of code has his own formatting and logic. I write GUI in xrc instead of wxs because all other windows was written in this format. This is what you point to? I can read about wxSmith, but I don't know where should I use it.
ad p.p.s. I was also thinking this way, but I followed by your advise:m.29:
Probably you need to modify the sdk and put most of the drawing code and data structures there.
If you do so all plugins can implement this graphical mode, not only the current one and there will be minimal code duplication.
See how it is done for the other features (watches, breakpoints, etc).
I look at how it is done for watches and then create similar cbVisualObject. I tried implement it as a separate plugin, but I don't know how, because I want to add functionality to GDBDebugger and I haven't access to its structures (e.g.: GDBWatch) in separate plugin.
-
Hmm, because I have to display data structures? :? What other way is possible to display them? Or what is it wrong specifically?
Why don't you use cbWatch as your data structure?
This was my initial idea.
Every plugin can implement this methods (AddVisualObject and DeleteVisualObject), and then create your own visual representation of watch. This representation will be created then by calling this method.
My idea was, that every plugin can implement your own representation of watch, which will be displayed on the canvas. My representation is tree control, but some other plugin can implement it other way.
No, you want the drawing and control code to be common for all plugins. The plugins should implement only data gathering.
See the MVC pattern. The View and the Controller should be common in the SDK or in additional plugin. Only the model should be implemented by debugger plugins.
ad p.s. I tried to do things similar to nearest code. I read articles about formatting and other advices in C::B, but I saw that every piece of code has his own formatting and logic. I write GUI in xrc instead of wxs because all other windows was written in this format. This is what you point to? I can read about wxSmith, but I don't know where should I use it.
True, most of the GUI is done using XRC, but this has/had happened before wxSmith.
ad p.p.s. I was also thinking this way, but I followed by your advise:m.29:
Probably you need to modify the sdk and put most of the drawing code and data structures there.
If you do so all plugins can implement this graphical mode, not only the current one and there will be minimal code duplication.
See how it is done for the other features (watches, breakpoints, etc).
I look at how it is done for watches and then create similar cbVisualObject. I tried implement it as a separate plugin, but I don't know how, because I want to add functionality to GDBDebugger and I haven't access to its structures (e.g.: GDBWatch) in separate plugin.
You've not followed it, because you have GUI in the plugin and if you look at this http://forums.codeblocks.org/index.php/topic,10908.0.html topic you'll see that I've tried to extract the GUI from the plugin.
What info do you need in GDBDebugger or GDBWatch that is not accessible through the SDK interfaces cbDebuggerPlugin and cbWatch?
-
I know what you mean now. My idea was the opposite, but I see this could be much better. So I will refactor my code and provide new patch.
What info do you need in GDBDebugger or GDBWatch that is not accessible through the SDK interfaces cbDebuggerPlugin and cbWatch?
I think only methods in GDBWatch:- IsArray
- GetArrayStart
- GetArrayCount
- GetIndex added by me
I know that in other languages (Python, ...) there are no arrays, but this methods could be more abstract like IsContainer, ... and added to cbWatch. What do you think about this idea?
-
Why do you care if the object is a container?
The cbWatch is a node in a tree, in fact, so if there are children the object is container somehow...
For example: if you have a watch object for an array: the elements of the array would be added as children cbWatch objects to the array cbWatch object.
Your drawing/visualizing code should only traverse the tree (asking every node in the three for its properties), see how it is done in the Watches window.
The drawing/visualizing should not care what the type of the watch is.
Probably we could add some hints, but I think it is doable without them.
p.s. IsContainer is hardly implementable in the DebuggerPlugin, because the Watch properties dialog is implemented in the plugin, not in the SDK.
-
I cared about that because I wanted to use another visualization for arrays (see image). But I write my own method to determine if watch is array. I check if children's symbol contains [ character :-|
I re-factored my code and moved sources to SDK. I think there is only model in the plugin. I'm posting my patch here in next few days. Hope you'll find time to check it and will give me the feedback on it. And thanks for the previous feedback :)
[attachment deleted by admin]
-
Great, I'm waiting for the patch :)
Hope it runs on linux :lol:
-
So I did the most of my TODOs and tried the patch on Ubuntu. On Ubuntu I found modifications like this one in patch:
@@ -232,7 +232,7 @@
</Linker>
</Target>
<Target title="Compiler depslib">
- <Option output="plugins/compilergcc/depslib/depslib" prefix_auto="1" extension_auto="1" />
+ <Option output="plugins/compilergcc/depslib/libdepslib" prefix_auto="1" extension_auto="1" />
<Option working_dir="" />
<Option type="2" />
<Option compiler="gcc" />I don't know what is it and why is there. Because of this there are not included modifications in "CodeBlocks-unix.cbp" file so on linux you need to add 10 files to project.
src/include/arraypanel.h
src/include/viewnode.h
src/include/viewvector.h
src/include/visualwatchesdlg.h
src/include/visualobject.h
src/sdk/arraypanel.cpp
src/sdk/viewnode.cpp
src/sdk/viewvector.cpp
src/sdk/visualwatchesdlg.cpp
src/sdk/visualobject.cpp
Hope it is not complication for you. I'm waiting for your feedback :-)
-
This change:
Index: src/plugins/debuggergdb/parsewatchvalue.cpp
===================================================================
--- src/plugins/debuggergdb/parsewatchvalue.cpp (revision 7112)
+++ src/plugins/debuggergdb/parsewatchvalue.cpp (working copy)
@@ -258,6 +258,8 @@
bool ParseGDBWatchValue(GDBWatch &watch, wxString const &value, int &start, int length)
{
watch.SetDebugValue(value);
+ // erase possible "Cannot access memory at address" at structural types
+ watch.SetValue(wxEmptyString);
watch.MarkChildsAsRemoved();
int position = start;
requires a unittest, explanation and steps to reproduce.
Also you're using C++, not C# or any other "modern" language, so "this->" is not required (99.99% of the time), when accessing members of the class.
Please don't do it.
I've not tried the patch yet, will do so tomorrow...
-
I tried this unittest with others and all tests passed:
// dereferenced pointer from invalid to valid address
TEST(DereferencedStructPointer)
{
GDBWatch w(wxT("*s"));
CHECK(ParseGDBWatchValue(w, wxT("Cannot access memory at address 0x0")));
CHECK(ParseGDBWatchValue(w, wxT("{\n number = 29,\n real = 36\n}")));
CHECK_EQUAL(wxT("*s= {number=29,real=36}"), w);
}Without my patch I get *s=Cannot access memory at address 0x0 {number=29,real=36}. You can reproduce this with this C code:#include <stdlib.h>
struct structure {
int number;
float real;
};
int main(void) {
struct structure *s = NULL;
struct structure S = {
.number = 29,
.real = 36,
};
s = &S;
return EXIT_SUCCESS;
}You set breakpoint at line struct structure *s = NULL; and then stop at line return EXIT_SUCCESS; As you can see at picture, old value is displayed.
In my code I hide edges of graph which are invalid. I find out this case (watch is invalid) by parsing watch value, but in some cases value of watch was invalid even if watch was was valid. Typically if dereferenced pointer was NULL and then not NULL.
Sorry for the "this->" issue. I'll remove it.
[attachment deleted by admin]
-
Applied with little modifications, thanks :)
p.s. Please don't attach images directly, because the forum space is limited. Use a picture paste type of service instead.
-
Wow, it really looks nice so far! I can't wait to see it working on my video editing project. Hey... can it be modified to display RGB pixels (if you specify a format) now that we're at it? :twisted: mwahahahahaha!
-
rickg22: probably you should get a copy of python enabled gdb and try to see what you can do with python scripting of gdb.
Hardcoding a bitmap viewer in the code doesn't sound good.