Re: Debugging multi-threaded programmes - I suggest compiling -O0 and Keep-It-Simple

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: [email protected]
>  [mailto:[email protected]] 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
> | [email protected]
> | http://lists.gnu.org/mailman/listinfo/ddd
>

_______________________________________________
Ddd mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/ddd

_______________________________________________
Ddd mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/ddd