From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 79485385828D for ; Sun, 29 Oct 2023 17:50:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 79485385828D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 79485385828D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698601821; cv=none; b=T/YDFgMthcwwjnww0VPIVbClbKzx/WnaKNLosipUeXOzcx6SHojGV6KR8d8/woc1JH9PS/E58+7FiqyME8dp8bxJMMjHcrgMbLdqDeGRjv6/jkaOSbzYoJXI+CXiTl4WrC49L35B3s4KygrZgzcve6qgZr1kF20kzZDkwOepKok= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698601821; c=relaxed/simple; bh=nkJY1ExZF5Id1biuLu4eHSP2PnORTUn1YVFqy1VSv7A=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=F09B6zkCpp4T4B3/WbOBOeMGlpbtX+ZDpWr2YQw38kZKdYx2CcpHTajIC8BLWO89zSUBL8+bfmWQEzD3NbjZVeMDbxLekzy6hSbBIST/bAxMH5t1MO+/7MEjgeFnbpw8Cnj1r0D/9CHfFrzol4akK+N0lXbE3/Naul7DKDu/VMU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qx9vW-0007Vh-TZ; Sun, 29 Oct 2023 13:50:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=espbOPlXOBdjsYIwxTIjLVYZYyugLhNe4fKM5pEogyk=; b=DQxdGDys6ntO yNQVGEITo9+/zljqTDV9dfJm/ZPGr+J3OulE+VYwexB5mmDQithpy3Xvsk8O0kzPzT+PPilRdijcT oi3ygXR7Rc/k2u+EKBtS3RK6puo88syz+9rAVIzc/ocy+/vfwTiAJfFD6z28sxJ6jN6dqzgeaq5CC Yifl0uVMyk9P1YE467CkERLtG5GVp459rn1j7Jzrm5ZmNk6hQrQoZSL7lNuWQ/PBkjXtPLgp1+eRo ldKDI14oEu1o4kY7LDJ77cavNxc1B+9DsUfcO/dNYwnxmSvrA2VJw8J27HcctH0/ofakBNXE09nln JAY7csRZq2gPgYm1Shoqsg==; Date: Sun, 29 Oct 2023 19:50:03 +0200 Message-Id: <835y2pb9o4.fsf@gnu.org> From: Eli Zaretskii To: Tom Tromey Cc: gdb-patches@sourceware.org In-Reply-To: <20231029173839.471514-7-tom@tromey.com> (message from Tom Tromey on Sun, 29 Oct 2023 11:35:25 -0600) Subject: Re: [PATCH 06/15] Add "maint set dwarf synchronous" References: <20231029173839.471514-1-tom@tromey.com> <20231029173839.471514-7-tom@tromey.com> X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > From: Tom Tromey > Cc: Tom Tromey > Date: Sun, 29 Oct 2023 11:35:25 -0600 > > For testing, it's sometimes convenient to be able to request that > DWARF reading be done synchronously. This patch adds a new "maint" > setting for this purpose. > --- > gdb/NEWS | 3 +++ > gdb/doc/gdb.texinfo | 14 ++++++++++++++ > gdb/dwarf2/read.c | 23 +++++++++++++++++++++++ > 3 files changed, 40 insertions(+) Thanks. > --- a/gdb/NEWS > +++ b/gdb/NEWS > @@ -9,6 +9,9 @@ > * GDB index now contains information about the main function. This speeds up > startup when it is being used for some large binaries. > > +* DWARF reading is now done in the background, resulting in faster startup. > + This can be controlled using "maint set dwarf synchronous". I'm guessing this isn't supported in all build configurations, and if so, this text should say so, and should give some indication which configurations don't support this feature. > --- a/gdb/doc/gdb.texinfo > +++ b/gdb/doc/gdb.texinfo > @@ -41692,6 +41692,20 @@ compilation units will be stored in memory longer, and more total > memory will be used. Setting it to zero disables caching, which will > slow down @value{GDBN} startup, but reduce memory consumption. > > +@kindex maint set dwarf synchronous > +@kindex maint show dwarf synchronous > +@item maint set dwarf synchronous > +@itemx maint show dwarf synchronous > +Control whether DWARF is read asynchronously. > + > +By default, the DWARF reader is mostly asynchronous with respect to > +the rest of @value{GDBN}. That is, the bulk of the reading is done in > +the background, and @value{GDBN} will only pause for completion of > +this task when absolutely necessary. > + > +When this setting is enabled, @value{GDBN} will instead wait for DWARF > +processing to complete before continuing. Same here. I'm guessing on platforms where this doesn't work, this setting doesn't have effect, and the default value is "synchronous"? > +/* Wait for DWARF reading to be complete. */ > +static bool dwarf_synchronous = false; > +static void > +show_dwarf_synchronous (struct ui_file *file, int from_tty, > + struct cmd_list_element *c, const char *value) > +{ > + gdb_printf (file, _("Whether DWARF reading is synchronous is %s.\n"), > + value); > +} The comment seems to describe a different function? > + add_setshow_boolean_cmd ("synchronous", class_obscure, > + &dwarf_synchronous, _("\ > +Set whether DWARF is read synchronously."), _("\ > +Show DWARF is read synchronously."), _("\ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "Show whether DWARF is read synchronously." > +By default, DWARF information is read in worker threads,\n\ > +and gdb will not generally wait for this process to complete.\n\ > +Enabling this setting will cause the DWARF reader to always wait\n\ > +for completion before gdb can proceed."), This could use some clarifications. The "wait for this process to complete" and "wait for completion before gdb can proceed" parts are somewhat mysterious: what exactly does "proceed" mean, and when it is important to wait for this to complete? IOW, this doc string leaves unsaid what processing needs DWARF reading to complete.