diff mbox

[2/2] gdb: Add missing #ifdef USE_THREAD_DB to gdbserver

Message ID 20171215000434.47315-2-jrtc27@jrtc27.com
State New, archived
Headers

Commit Message

Jessica Clarke Dec. 15, 2017, 12:04 a.m. UTC 
  gdb/ChangeLog:
	* gdbserver/linux-low.c (handle_extended_wait): Surround call to
	thread_db_notice_clone with #ifdef USE_THREAD_DB.
---
[Originally erroneously sent to the binutils mailing list]

 gdb/gdbserver/linux-low.c |    2 ++
 1 file changed, 2 insertions(+)

--
1.7.10.4

Comments

Pedro Alves Jan. 19, 2018, 4:48 p.m. UTC | #1 
On 12/15/2017 12:04 AM, James Clarke wrote:
> gdb/ChangeLog:
> 	* gdbserver/linux-low.c (handle_extended_wait): Surround call to
> 	thread_db_notice_clone with #ifdef USE_THREAD_DB.
> ---
> [Originally erroneously sent to the binutils mailing list]

Looks OK, but could you remind me what goes wrong if we
don't do this?  Does gdbserver fail to link?

Thanks,
Pedro Alves
Jessica Clarke Jan. 19, 2018, 4:55 p.m. UTC | #2 
On 19 Jan 2018, at 16:48, Pedro Alves <palves@redhat.com> wrote:
> On 12/15/2017 12:04 AM, James Clarke wrote:
>> gdb/ChangeLog:
>> 	* gdbserver/linux-low.c (handle_extended_wait): Surround call to
>> 	thread_db_notice_clone with #ifdef USE_THREAD_DB.
>> ---
>> [Originally erroneously sent to the binutils mailing list]
> 
> Looks OK, but could you remind me what goes wrong if we
> don't do this?  Does gdbserver fail to link?

Yes, with the expected:

> [...]/linux-low.c:664: undefined reference to `thread_db_notice_clone(thread_info*, ptid_t)'

Every other use of thread_db_* is guarded by USE_THREAD_DB, so I assume it's
fine to do here too.

Regards,
James
Pedro Alves Jan. 19, 2018, 4:57 p.m. UTC | #3 
On 01/19/2018 04:55 PM, James Clarke wrote:
> On 19 Jan 2018, at 16:48, Pedro Alves <palves@redhat.com> wrote:
>> On 12/15/2017 12:04 AM, James Clarke wrote:
>>> gdb/ChangeLog:
>>> 	* gdbserver/linux-low.c (handle_extended_wait): Surround call to
>>> 	thread_db_notice_clone with #ifdef USE_THREAD_DB.
>>> ---
>>> [Originally erroneously sent to the binutils mailing list]
>>
>> Looks OK, but could you remind me what goes wrong if we
>> don't do this?  Does gdbserver fail to link?
> 
> Yes, with the expected:
> 
>> [...]/linux-low.c:664: undefined reference to `thread_db_notice_clone(thread_info*, ptid_t)'
> 
> Every other use of thread_db_* is guarded by USE_THREAD_DB, so I assume it's
> fine to do here too.

Thanks for the clarification.  Please add that to the commit log,
and push it in.

Thanks,
Pedro Alves
Jessica Clarke Jan. 19, 2018, 5:01 p.m. UTC | #4 
On 19 Jan 2018, at 16:57, Pedro Alves <palves@redhat.com> wrote:
> On 01/19/2018 04:55 PM, James Clarke wrote:
>> On 19 Jan 2018, at 16:48, Pedro Alves <palves@redhat.com> wrote:
>>> On 12/15/2017 12:04 AM, James Clarke wrote:
>>>> gdb/ChangeLog:
>>>> 	* gdbserver/linux-low.c (handle_extended_wait): Surround call to
>>>> 	thread_db_notice_clone with #ifdef USE_THREAD_DB.
>>>> ---
>>>> [Originally erroneously sent to the binutils mailing list]
>>> 
>>> Looks OK, but could you remind me what goes wrong if we
>>> don't do this?  Does gdbserver fail to link?
>> 
>> Yes, with the expected:
>> 
>>> [...]/linux-low.c:664: undefined reference to `thread_db_notice_clone(thread_info*, ptid_t)'
>> 
>> Every other use of thread_db_* is guarded by USE_THREAD_DB, so I assume it's
>> fine to do here too.
> 
> Thanks for the clarification.  Please add that to the commit log,
> and push it in.

I don't have push rights, so I'll email a v2 to be committed on my behalf.

Regards,
James
diff mbox

Patch

diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c
index f6a52d5..398cd70 100644
--- a/gdb/gdbserver/linux-low.c
+++ b/gdb/gdbserver/linux-low.c
@@ -661,7 +661,9 @@  handle_extended_wait (struct lwp_info **orig_event_lwp, int wstat)
 	  new_lwp->status_pending = status;
 	}

+#ifdef USE_THREAD_DB
       thread_db_notice_clone (event_thr, ptid);
+#endif

       /* Don't report the event.  */
       return 1;