Aref Taidi wrote:
> Many thanks for your replies and
help. I guess I have to compile with O0
> when I have a problem and after sorting it out switch back to O2.
This would
> cause other problems which we don't go into, but as long as the
finished
> product is built with O2 and works then I shouldn't complain!
>
> The next thing to do is to find out how to attach/detach to live
threads,
> but I guess that's a matter of reading some manuals.
Just attach to the process and do info threads.
Place breakpoint and run. Threads share the same
text space so a breakpoint can effect multiple threads.
-piet
>
> Many thanks again for your help.
>
> Aref
>
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden] On
Behalf Of
> Pete/Piet Delaney
> Sent: 24 June 2008 06:49
> To: Discussion list for DDD,the GNU graphical debugger front end
> Cc: 'Piet Delaney'; Piet Delaney
> Subject: Re: Debugging multi-threaded programmes - I suggest
compiling -O0
> and Keep-It-Simple
>
Fabian Scheler wrote:
| Hello Aref,
|
|> Is there an extensive use of ddd over gdb for debugging
multi-threaded
|> applications, or in other words how reliable or easy is it to do
this,
|> especially for hard real time applications in Linux user space?
|
| I would suppose this to be as stable as debugging threads with gdb and
| I suppose that to work. Debugging real-time applications, however, is
| another issue, as you have to be aware of the probe effect caused by
| debuggers like gdb ...
|
|> I have had a lot of difficulties doing this and I sincerely hope
someone can
|> help. I am having a range of problems with ddd version 3.3.11 on
top
of gdb
|> version 6.3.0.0-1.122rh. The most annoying problem is local
variables not
|> known to the gdb - I get "No symbol "fred" in current context"
although that
|> may be a gdb problem. I have compiled my programme with:
I you compile -O0 your locals will be visible and almost everything
will be nice and easy. I don't recall a problem with threads when
I worked on a user space application that used threads. Threads problems
were more confined to compile options to enable the use of locks with
the threads in openssl. I think ddd worked fine. I usually set the
openssl debug enable with then compiled -O0 as I recall.
|
| Did you try 'Data'->'Display Local Variables' in the Menu. Normally
| the compiler does not generate symbols for local variables (these
| variables just exist on the stack) and so you cannot add a display for
| them.
|
| Besides that: I would not switch to -O0, gcc does not perform register
| allocation with -O0 and so the code finally generated has nothing to
| do with the real code that will actually be run. I would use compiler
| switches as close as possible to the real ones.
I prefer to debug the kernel with -O0 and convert 'static inlines' to
static. I increase the maximum stack size to compensate for the
increased number of frames on the stack.
I suppose it's like religion, lots of points of view. I like to keep the
debugging env as transparent as possible. Others like to minimally
change timing. Your choice.
-piet
|
| Ciao, Fabian
|
|
| _______________________________________________
| Ddd mailing list
| address@hidden
| http://lists.gnu.org/mailman/listinfo/ddd
_______________________________________________
Ddd mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/ddd
|