RE: [cdt-dev] Couple issues with DSF

["Marc Khouzam" <marc.khouzam@xxxxxxxxxxxx>]

> Dmitry Smirnov
> Sent: Wednesday, February 11, 2009 9:48 AM
> 
> 2009/2/10 Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>:
> > 6.3 is quite old. (auto-solib-add does not exist in that version, I
> > believe)
> > I think we support back to 6.6.
> > Your best bet is to try 6.8.  Is that possible?
> 
> Well, yes, I can do it, but the problem is that my company' CM does
> support that one.
> 
> BTW, is that auto-solib-add is the only feature that you are using
> from newer versions?

There are probably a bunch of other limitations to support 6.3
We basically ran some tests with 6.6, 6.7 and 6.8.
Maybe 6.3 won't be a huge effort to support, so if you want to 
run some test and report bugs, we can see how much work it would be.

> Is it possible to not terminate debug session at least?

You mean that the session aborts when auto-solib-add fails?
I could turn that off, but I'm guessing other things will fail also.
The easiest way would be for you to modify DSG-GDB in your workspace
and keep testing 6.3.  Then you can report what you found.


> > What is the syntax you would use in the GDB command line to trigger
> > a 'halt on connection'?  If it is a breakpoint, maybe we can try
> > changing the "Stop on startup" option in the launch, or to have your
> > breakpoint already defined before you launch.
> > If that does not work, then we probably need a new option...
> 
> Nothing specific in GDB. I suppose Hardware Debugging also does
> nothing. It just does not start (run) or resume (continue) debugging
> after target remote:<port> command.

So there is value (sometimes) in connecting to the target and
immediately
giving control to the user?  I guess there could be an option in the
launch
for that.  Does CDI support it?  do you know?
Can you write a bug?

> > Do you have the DSF logs from the console?
> > If not, then can you try the command
> > -stack-list-frames
> > from the eclipse console, once you got to the point where 
> DSF does not
> > show the stack?
> > I'm curious to see if GDB gives us back enough data.
> 
> This command does not give any data
> 
> info threads
> * 1 Thread <main>  tmc_init () at qct\services\tmc\tmc.c:11541
> warning: RMT ERROR : failed to get remote thread list.
> -stack-list-frames

This may also be related to 6.3
MI was not very complete in older GDBs

> 
> bt
> #0  tmc_init () at qct\services\tmc\tmc.c:11541
> #1  0x00c1d4c6 in tmc_task (ignored=<value optimized out>)
>     at qct\services\tmc\tmc.c:12350
> #2  0x00eee43e in rex_thread_init (entrypoint=0xc1d4a9 <tmc_task+1>)
>     at qct\services\rexl4\rexl4.c:174
> #3  0x00f3e0c8 in __thread_stub ()
> #4  0x00f3e0c8 in __thread_stub ()
> Backtrace stopped: previous frame identical to this frame 
> (corrupt stack?)
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>