From: Michael Snyder <msnyder@vmware.com>
To: "nagaraju.m" <nagaraju.m@redpinesignals.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: processor threads
Date: Thu, 22 Oct 2009 20:19:00 -0000 [thread overview]
Message-ID: <4AE09DB8.40801@vmware.com> (raw)
In-Reply-To: <4AE00144.5020201@redpinesignals.com>
nagaraju.m wrote:
> Michael,
>
> Thanks for replying.
>
> Can you please forward me any links on how to implement threads support
> to a specific target.
Probably you want to look at the remote serial protocol.
Start here: http://sourceware.org/gdb/current/onlinedocs/gdb_37.html#SEC677
Look for the messages pertaining to threads. There are several.
For instance.
* set and query the "current" thread
* query if a thread is still alive
There is not a special query for the registers of a particular
thread. Instead, gdb will ask the target to set the "current"
thread for thread queries, and then gdb will just ask for
registers. It being implied that the registers should come from
the "current" thread.
> Michael Snyder wrote:
>> nagaraju.m wrote:
>>> Hi Michael,
>>>
>>> I mean to say that we are having 4 hardware threads. Our company
>>> has its own processor on which we will be working. The
>>> processor currently we are working has 4 threads in it.
>>>
>>> Each thread has it own set of registers (ex: program counter).
>>>
>>> Currently the GDB which we are using is supporting only single
>>> thread (ex: thread 0).
>>> Now we trying to use GDB for remaining threads.
>>>
>>> My Question is does GDB handles hardware threads??
>> Good, thank you for the clarification.
>>
>> The answer is "yes and no". GDB supports threads, per se, but
>> it doesn't have any special knowledge about hardware threads
>> as opposed to any other kind of threads.
>>
>> What you can do (and what others have done successfully before),
>> is just teach your remote server/stub/agent to tell gdb
>> "I have four threads, and here are their register sets".
>>
>> Gdb will then just think of them as ordinary threads.
>> Should be enough for you to get the job done, with maybe
>> a few extra tweaks that can be snuck in as off-band
>> monitor commands.
>>
>> Good luck,
>> Michael
>>
>>
>>
>
next prev parent reply other threads:[~2009-10-22 18:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-20 7:35 nagaraju.m
2009-10-20 17:55 ` Paul Pluzhnikov
2009-10-20 17:58 ` Michael Snyder
2009-10-21 6:05 ` nagaraju.m
2009-10-21 8:58 ` Jie Zhang
2009-10-21 14:34 ` Michael Snyder
2009-10-22 15:23 ` nagaraju.m
2009-10-22 20:19 ` Michael Snyder [this message]
2009-10-24 16:03 ` Jie Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AE09DB8.40801@vmware.com \
--to=msnyder@vmware.com \
--cc=gdb@sourceware.org \
--cc=nagaraju.m@redpinesignals.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox