From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id E5D3E385782C for ; Wed, 14 Apr 2021 01:46:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E5D3E385782C Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 13E1jsZ1012666 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Apr 2021 21:45:59 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 13E1jsZ1012666 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id BD9711E54D; Tue, 13 Apr 2021 21:45:53 -0400 (EDT) Subject: Re: GDB 10.2 Release -- 2021-04-11 update To: Kevin Buettner Cc: gdb-patches@sourceware.org, Joel Brobecker , Pedro Alves References: <20210411053920.GA1629728@adacore.com> <20210411230018.30827d60@f33-m1.lan> <20210412211855.771ff58a@f33-m1.lan> From: Simon Marchi Message-ID: Date: Tue, 13 Apr 2021 21:45:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210412211855.771ff58a@f33-m1.lan> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 14 Apr 2021 01:45:54 +0000 X-Spam-Status: No, score=-10.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 01:46:04 -0000 On 2021-04-13 12:18 a.m., Kevin Buettner wrote:> On Mon, 12 Apr 2021 10:04:44 -0400 > Simon Marchi wrote: > >>>> This looks like a difficult issue to solve, with both GDB *and* >>>> GDBserver needing a fix, and no clear indication that I could see >>>> that they would be getting a similar fix. With that in mind, >>>> I'm wondering if we shouldn't give ourselves a deadline after which >>>> we simply accept this as a known limitation of the 10.2 release, >>>> and work on fixing it for the GDB 11 release instead. >>> >>> So... I have the beginnings of a patch for gdbserver. I'm tracking >>> down some regressions though, so don't have anything I can share >>> quite yet. >> >> I didn't have time to look at GDBserver yet. Could you share your patch >> (it could be just a link to an external git repo) even if it's not ready >> yet? > > My current patch is below. It's small, so I decided to post it in > this reply. > > It no longer works for the case which originally got me interested in > this problem (which is gdb.threads/fork-plus-threads.exp w/ > --target_board=native-extended-gdbserver), but it also no longer > causes regressions in gdb.threads/tls.exp. Things are getting further > though - i.e. _rtld_global is now being found. > > Things are going astray further along, but I'm not quite sure where > yet. I'm still working on it... > > diff --git a/gdbserver/thread-db.cc b/gdbserver/thread-db.cc > index 055a0fa970f..9403b419710 100644 > --- a/gdbserver/thread-db.cc > +++ b/gdbserver/thread-db.cc > @@ -44,10 +44,14 @@ struct thread_db > /* Connection to the libthread_db library. */ > td_thragent_t *thread_agent; > > - /* If this flag has been set, we've already asked GDB for all > - symbols we might need; assume symbol cache misses are > - failures. */ > - int all_symbols_looked_up; > + /* This flag is set after asking GDB for symbols that we need. It > + does not, however, indicate that all necessary symbols have found > + as these may be split among several shared objects. */ > + bool initialized; > + > + /* Flag which indicates that it's okay to ask GDB for symbols via > + a qSymbol reply. */ > + bool qsymbol_reply_okay; > > #ifndef USE_LIBTHREAD_DB_DIRECTLY > /* Handle of the libthread_db from dlopen. */ > @@ -359,19 +363,20 @@ thread_db_look_up_symbols (void) > const char **sym_list; > CORE_ADDR unused; > > + thread_db->qsymbol_reply_okay = true; > + > for (sym_list = thread_db->td_symbol_list_p (); *sym_list; sym_list++) > look_up_one_symbol (*sym_list, &unused, 1); > > - /* We're not interested in any other libraries loaded after this > - point, only in symbols in libpthread.so. */ > - thread_db->all_symbols_looked_up = 1; > + thread_db->qsymbol_reply_okay = false; > + thread_db->initialized = true; > } > > int > thread_db_look_up_one_symbol (const char *name, CORE_ADDR *addrp) > { > struct thread_db *thread_db = current_process ()->priv->thread_db; > - int may_ask_gdb = !thread_db->all_symbols_looked_up; > + int may_ask_gdb = thread_db->qsymbol_reply_okay || !thread_db->initialized; > > /* If we've passed the call to thread_db_look_up_symbols, then > anything not in the cache must not exist; we're not interested > @@ -396,7 +401,7 @@ thread_db_get_tls_address (struct thread_info *thread, CORE_ADDR offset, > thread_db = proc->priv->thread_db; > > /* If the thread layer is not (yet) initialized, fail. */ > - if (thread_db == NULL || !thread_db->all_symbols_looked_up) > + if (thread_db == NULL || !thread_db->initialized) > return TD_ERR; > > /* If td_thr_tls_get_addr is missing rather do not expect td_thr_tlsbase > @@ -888,7 +893,7 @@ thread_db_notice_clone (struct thread_info *parent_thr, ptid_t child_ptid) > > /* If the thread layer isn't initialized, return. It may just > be that the program uses clone, but does not use libthread_db. */ > - if (thread_db == NULL || !thread_db->all_symbols_looked_up) > + if (thread_db == NULL || !thread_db->initialized) > return; > > /* find_one_thread calls into libthread_db which accesses memory via > Thanks! So from what I understand, the problem is that GDB offers GDBserver the opportunity to look up some symbols in between each objfile read in the initial library scan. After GDB has loaded lipthread (but not ld-linux yet), libthread_db fails to work because GDB doesn't know the ld-linux symbols yet. It sounds very much like the non-GDBserver case. I see that you are trying to fix that GDBserver-side (although I don't quite get what you are trying to do, perhaps a quick explanation would help). Could we instead tackle it GDB-side, with the same idea as what I proposed the native debugging? We could suppress the qsymbol packets sent in between each objfile loaded from the initial library scan. We would have a single qsymbol sent after finishing loading all the initial libraries. For example, I just hacked this, this makes it work for the simple non-stop attach case with gdbserver, where you run gdbserver with --attach and then connect with GDB (I haven't tried the other modes). The final qsymbol, that lets GDBserver load libthread_db, is sent in remote_target::start_remote. >From b6f8afc01e0e6377e27da640b809d6013e02cc3f Mon Sep 17 00:00:00 2001 From: Simon Marchi Date: Tue, 13 Apr 2021 21:33:37 -0400 Subject: [PATCH] blah Change-Id: I601aaf0b9bf3040b85ce7ba675afdd8986c56a34 --- gdb/remote.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/gdb/remote.c b/gdb/remote.c index 7429e1a86b38..282f4cfafbff 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -252,6 +252,8 @@ class remote_state about the remote side's threads, relocating symbols, etc.). */ bool starting_up = false; + bool some_other_boolean = false; + /* If we negotiated packet size explicitly (and thus can bypass heuristics for the largest packet size that will not overflow a buffer in the stub), this will be set to that packet size. @@ -4886,7 +4888,9 @@ remote_target::start_remote (int from_tty, int extended_p) strcpy (rs->buf.data (), wait_status); rs->cached_wait_status = 1; + rs->some_other_boolean = true; ::start_remote (from_tty); /* Initialize gdb process mechanisms. */ + rs->some_other_boolean = false; } else { @@ -14515,7 +14519,7 @@ remote_new_objfile (struct objfile *objfile) { remote_target *remote = get_current_remote_target (); - if (remote != NULL) /* Have a remote connection. */ + if (remote != NULL && !remote->get_remote_state()->some_other_boolean) /* Have a remote connection. */ remote->remote_check_symbols (); } -- 2.30.1