This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to catch GDB crash


A Wednesday 02 July 2008 13:50:00, Dmitry Smirnov wrote:

> I'm wondering why GDB is trying to get ThreadExtraInfo if stub has
> responded that it does not support threads? BTW, I didn't see this "Reply
> contains invalid hex digit 84" in older GDBs.

That's because versions of GDB until about a week ago didn't register
a main thread/task in the internal thread table if the target didn't
report thread support.  Now we're always registering a main
thread even in that case.  When you do "info threads", GDB queries
the target side for more info on each of the registered
threads.  Since previously there was 0 threads registered, there
were 0 qThreadExtraInfo queries performed.  Now, there's a thread, so
GDB core does 1 query.  But, since this thread was added internally
by GDB behind the remote side's back, we need to bar it just
before letting the query out to the remote side.  That's what
this new patch does.

> Does stub HAVE to support it?

No, it's optional.  But if the stub doesn't support it, it MUST
reply an empty response (an empty C string, as for all
unsupported packets).  Failing to do that is what looks
like a bug in the simulator.

> P.S. I'll test your patch a little bit later and come back with results.

Thanks!

-- 
Pedro Alves
l


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]