From: "Amit S. Kale" <amitkale@emsyssoft.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb@sources.redhat.com
Subject: Re: gdbserver ps_lgetregs implementation for nptl
Date: Fri, 12 Dec 2003 15:07:00 -0000 [thread overview]
Message-ID: <200312122036.57453.amitkale@emsyssoft.com> (raw)
In-Reply-To: <20031211141429.GB26315@nevyn.them.org>
Implementing the commented out code was trivial for i386 because it already
has register sets. I implemented all ps_*getregs functions.
A change was needed in gdb. I had to add support for qSymbol in
remote.c:remote_wait. This was needed for a symbol query from nptl.
I am pasting below code from ps_lsetregs modified by me. I removed creation of
a register cache. before fetch_registers and fill_function. Is this the right
way of doing it?
----
ps_err_e
ps_lgetregs (gdb_ps_prochandle_t ph, lwpid_t lwpid, prgregset_t gregset)
{
struct thread_info *reg_inferior, *save_inferior;
reg_inferior = (struct thread_info *) find_inferior_id (&all_threads,
lwpid);
if (reg_inferior == NULL)
return PS_ERR;
save_inferior = current_inferior;
current_inferior = reg_inferior;
the_target->fetch_registers (0);
gregset_info()->fill_function (gregset);
current_inferior = save_inferior;
return PS_OK;
}
-----
On Thursday 11 Dec 2003 7:44 pm, Daniel Jacobowitz wrote:
> On Thu, Dec 11, 2003 at 03:13:23PM +0530, Amit S. Kale wrote:
> > Hi,
> >
> > I am trying to debug nptl programs using gdbserver on x86 platform. First
> > problem I found was missing ps_get_thread_area, which was easy to copy
> > from the implementation in gdb. Then error return from ps_lgetregs caused
> > a problem. ps_lgetregs has come code, though it's commented out. Any
> > ideas on completing that code?
>
> I've been meaning to make it work with NPTL and not found the time...
> However, it will take more than making it load to make it work. I
> expect that it will also require an extension to the remote protocol to
> query the thread base address.
>
> ps_get_thread_area in LinuxThreads was only called by functions that
> gdbserver did not use. If it's necessary for LinuxThreads - it appears
> to be - then you'll have to supply a working version. This will
> require describing register sets in gdbserver, which it already can do
> on some platforms (see the code that uses PTRACE_GETREGS).
--
Amit Kale
EmSysSoft (http://www.emsyssoft.com)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)
next prev parent reply other threads:[~2003-12-12 15:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-11 9:43 Amit S. Kale
2003-12-11 14:14 ` Daniel Jacobowitz
2003-12-12 15:07 ` Amit S. Kale [this message]
2003-12-12 18:18 ` Daniel Jacobowitz
2003-12-13 18:39 ` Jim Blandy
2003-12-15 6:08 ` Amit S. Kale
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=200312122036.57453.amitkale@emsyssoft.com \
--to=amitkale@emsyssoft.com \
--cc=drow@mvista.com \
--cc=gdb@sources.redhat.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