public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
From: sergiodj+buildbot@sergiodj.net
To: gdb-testers@sourceware.org
Subject: [binutils-gdb] gdbserver: Remove gdb_id_to_thread_id
Date: Fri, 15 Sep 2017 17:56:00 -0000	[thread overview]
Message-ID: <96cde54f0adf2315404f3eba35dc3dfbc57f98c8@gdb-build> (raw)

*** TEST RESULTS FOR COMMIT 96cde54f0adf2315404f3eba35dc3dfbc57f98c8 ***

Author: Simon Marchi <simon.marchi@ericsson.com>
Branch: master
Commit: 96cde54f0adf2315404f3eba35dc3dfbc57f98c8

gdbserver: Remove gdb_id_to_thread_id

>From what I understand, this function is not doing anything useful as of
today.

Here's the result of my archeological research:

- The field thread_info::gdb_id was added in

  a06660f7  Use LWP IDs for thread IDs in gdbserver

  There was problem when using a 32-bits gdb with a 64-bits gdbserver.
  For some reason that I don't fully understand, the thread ids
  exchanged between gdb and gdbserver could overflow a 32 bits data
  type.  My guess is that they were the thread address (e.g. the
  0x7ffff7f20b40 in "Thread 0x7ffff7f20b40 (LWP 1058)" today).  This
  patch changed that so gdb/gdbserver would talk in terms of the OS
  assigned numerical id (as shown in ps).  It therefore added a way to
  convert between this gdb_id (the numerical id) and the thread id (the
  address).

- 95954743cb  Implement the multiprocess extensions, and add linux
              multiprocess supportNon-stop mode support.

  This patch made gdbserver deal with threads using their numerical ids
  and not the address-like id.  Starting from there, the gdb_id <->
  thread id conversion was not needed anymore, since the remote protocol
  and gdbserver were using the same kind of ids again.  The gdb_id field
  in the thread_info structure was also unused starting there.

- d50171e4  Teach linux gdbserver to step-over-breakpoints.

  This patch moved the thread_info structure around, and got rid of the
  gdb_id field (which was unused).

Looking at the implementation of gdb_id_to_thread_id, it is not doing
anything useful.  It is looking up a thread by ptid using
find_thread_ptid, which basically loops over all threads looking at
their entry.id field.  If a thread with that ptid is found, it returns
its entry.id field.  So it will always return the same thing as it input
(with the exception of if no thread exist with that ptid, then it will
return null_ptid).

gdb/gdbserver/ChangeLog:

	* inferiors.h (gdb_id_to_thread_id): Remove.
	* inferiors.c (gdb_id_to_thread_id): Remove.
	* server.c (process_serial_event): Adjust to gdb_id_to_thread_id
	removal.  Move pid declaration closer to where it's used.


             reply	other threads:[~2017-09-15 17:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-15 17:56 sergiodj+buildbot [this message]
2017-09-15 17:58 ` Failures on Fedora-s390x-m64, branch master sergiodj+buildbot
2017-09-15 19:08 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot
2017-09-15 19:24 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot
2017-09-15 19:47 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " sergiodj+buildbot
2017-09-15 19:56 ` Failures on Fedora-x86_64-m64, " sergiodj+buildbot
2017-09-15 20:03 ` Failures on Fedora-x86_64-native-gdbserver-m64, " sergiodj+buildbot
2017-09-15 20:06 ` Failures on Fedora-i686, " sergiodj+buildbot
2017-09-15 20:07 ` Failures on Fedora-x86_64-m32, " sergiodj+buildbot
2017-09-15 21:00 ` Failures on Ubuntu-AArch64-m64, " sergiodj+buildbot
2017-09-15 21:30 ` Failures on Ubuntu-AArch32-m32, " sergiodj+buildbot
2017-09-15 22:41 ` Failures on Ubuntu-AArch32-native-extended-gdbserver-m32, " sergiodj+buildbot
2017-10-03 10:54 ` Failures on Debian-s390x-m64, " sergiodj+buildbot
2017-10-03 20:02 ` Failures on Debian-s390x-native-extended-gdbserver-m64, " sergiodj+buildbot
2017-10-04 23:34 ` Failures on Debian-s390x-native-gdbserver-m64, " sergiodj+buildbot

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=96cde54f0adf2315404f3eba35dc3dfbc57f98c8@gdb-build \
    --to=sergiodj+buildbot@sergiodj.net \
    --cc=gdb-testers@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).