OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

[gdbserver/lynx178]: Fix null_ptid -vs- minus_one_ptid confusion in comment 

gdb/gdbserver/ChangeLog:

        * lynx-low.c (lynx_resume): Fix null_ptid/minus_one_ptid
        confusion in comment.
This commit is contained in:
Joel Brobecker 2013-05-17 06:53:53 +00:00
parent d631c5a779
commit 58794e1a64
2 changed files with 10 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
gdb/gdbserver/ChangeLog
View File

@ -1,3 +1,8 @@
2013-05-17 Joel Brobecker <brobecker@adacore.com>
* lynx-low.c (lynx_resume): Fix null_ptid/minus_one_ptid
confusion in comment.
2013-05-17 Joel Brobecker <brobecker@adacore.com>
* lynx-low.c (struct process_info_private): New type.

10
gdb/gdbserver/lynx-low.c
View File

@ -284,7 +284,7 @@ lynx_resume (struct thread_resume *resume_info, size_t n)
? PTRACE_SINGLESTEP : PTRACE_CONT);
const int signal = resume_info[0].sig;
/* If given a null_ptid, then try using the current_process'
/* If given a minus_one_ptid, then try using the current_process'
private->last_wait_event_ptid. On most LynxOS versions,
using any of the process' thread works well enough, but
LynxOS 178 is a little more sensitive, and triggers some
@ -293,10 +293,10 @@ lynx_resume (struct thread_resume *resume_info, size_t n)
if (ptid_equal (ptid, minus_one_ptid))
ptid = current_process()->private->last_wait_event_ptid;
/* The ptid might still be NULL; this can happen between the moment
we create the inferior or attach to a process, and the moment
we resume its execution for the first time. It is fine to
use the current_inferior's ptid in those cases. */
/* The ptid might still be minus_one_ptid; this can happen between
the moment we create the inferior or attach to a process, and
the moment we resume its execution for the first time. It is
fine to use the current_inferior's ptid in those cases. */
if (ptid_equal (ptid, minus_one_ptid))
ptid = thread_to_gdb_id (current_inferior);