From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 3299C3858C30 for ; Mon, 2 Oct 2023 16:05:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3299C3858C30 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1696262754; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9a4ZubMS+wFTNE05u3ArKqPads0vlyXL/Z0i22OWbK4=; b=dK7Ktn2bTzquU7ldjsoD6kCk/cOSzmNqzcBt8x/Idj0ThGPkVZtb9Tr2gTI4YaCjZ0YXQl JSK7g3WH7WZLgC7TqoDc2J5tEr3/025YYie0ZAZzwlZYUzfdZNsGceO4CUK4jPzBE6hHiH q+ahysVwJBj+aqLM/K2peYtjYGM7VFs= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-689-JjES7qULNfOBFfJoiRTyEg-1; Mon, 02 Oct 2023 12:05:53 -0400 X-MC-Unique: JjES7qULNfOBFfJoiRTyEg-1 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-9ae7663e604so1280010666b.3 for ; Mon, 02 Oct 2023 09:05:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696262752; x=1696867552; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9a4ZubMS+wFTNE05u3ArKqPads0vlyXL/Z0i22OWbK4=; b=cHZjucKPFT1TPYIRIybGbuuVDIk8NYrHsWWt+vAMq8UZMb0qcLdhfQ+7lQZVaG6PUm ye9xSKfYbI8TLNF7GGX9jJrXZZoykUi4oQrEkKg+XTldDzykjFsHsOw9/QywbFnsTnJJ fJmHq2fdJtJinE6Q8eW0QWyIk5r87uEoGvnBC8mEU7lu1O/4g8JBQS2yLeZu19/rrcrS xAzK3lrMS+kfit2Xk/Sfr57BMiTP8x72EmgH8Nyg9MSwfw8eXUwfVW7RIezG9VkQAx5f FVTG6p05Co3R1B1L15bbK5EZDKs0No1k+KDqWFL6XsM00aB+zOEdOqzDSmK9wKh/+1CE 0u5w== X-Gm-Message-State: AOJu0YxLBFhesD1ImxPRN0WZWE6dDuSljSAtiQFyX+bU4UK29r9RKcxt Cvd+AUrXzBC/RnvvnPdzmDgsC/PWeAU+TlPg52Oy6L1MIVTs79LV6qvvGYqSQfuI2EZDRum8ju0 rqfpy7Z2fztTEoc2pIR0hiw== X-Received: by 2002:a17:906:5a45:b0:9b6:5813:f627 with SMTP id my5-20020a1709065a4500b009b65813f627mr639799ejc.1.1696262751842; Mon, 02 Oct 2023 09:05:51 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFCM4ZVqiy70amnpPxeMSJFaooZ9p+QtNNshLaJbuMh7BCLu9tmnb+6nQQ5LSpoK8TxzxaQsA== X-Received: by 2002:a17:906:5a45:b0:9b6:5813:f627 with SMTP id my5-20020a1709065a4500b009b65813f627mr639783ejc.1.1696262751487; Mon, 02 Oct 2023 09:05:51 -0700 (PDT) Received: from localhost ([31.111.84.209]) by smtp.gmail.com with ESMTPSA id j26-20020a170906831a00b0099275c59bc9sm17230076ejx.33.2023.10.02.09.05.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Oct 2023 09:05:51 -0700 (PDT) From: Andrew Burgess To: Tom Tromey Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCHv2 5/5] gdb: fix reread_symbols when an objfile has target: prefix In-Reply-To: <87lecl1500.fsf@tromey.com> References: <87il7u2mdo.fsf@tromey.com> <87pm21uvq9.fsf@redhat.com> <87lecl1500.fsf@tromey.com> Date: Mon, 02 Oct 2023 17:05:49 +0100 Message-ID: <87fs2txb4y.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: Tom Tromey writes: >>>>>> "Andrew" == Andrew Burgess writes: > >>> The BFD cache (in gdb_bfd.c) uses fstat, so I think there would still be >>> a problem here. > > Andrew> OK, but the original mtime is captured via a call to bfd_stat. > > Andrew> Isn't the problem when we have two mismatched calls. Using bfd_stat in > Andrew> one place (a.k.a. system stat/fstat) vs a direct call to stat/fstat from > Andrew> GDB in another place (a.k.a. gnulib stat/fstat). > > Andrew> In this patch I'm proposing that we _consistently_ call bfd_stat. Sure > Andrew> that might disagree with system stat/fstat -- but who cares? So long as > Andrew> the time being calculated and compared to is a BFD time_t result then we > Andrew> should be fine .... or am I really not understanding the problem? > > I think the fstat in gdb_bfd.c means that we will always re-read the > debug info, because now gdb_bfd_open will use fstat (and this is what is > recorded in the hash table), but reread_symbols will use bfd_stat. I really don't think this is the case. The code in reread_symbols is this: int res; struct stat new_statbuf; if (objfile->obfd->my_archive) res = stat (bfd_get_filename (objfile->obfd->my_archive), &new_statbuf); else res = stat (objfile_name (objfile), &new_statbuf); if (res != 0) { /* FIXME, should use print_sys_errmsg but it's not filtered. */ gdb_printf (_("`%s' has disappeared; keeping its symbols.\n"), objfile_name (objfile)); continue; } time_t new_modtime = new_statbuf.st_mtime; if (new_modtime != objfile->mtime) { gdb_printf (_("`%ps' has changed; re-reading symbols.\n"), styled_string (file_name_style.style (), objfile_name (objfile))); ... } So we perform a system 'stat' call and compare this to objfile::mtime. And objfile::mtime is initialised in objfiles.c with this code: if (obfd != nullptr) { mtime = bfd_get_mtime (obfd.get ()); /* Build section table. */ build_objfile_section_table (this); } Where bfd_get_mtime is going to fetch a value by calling bfd_stat, which will either by the system stat (linked into libbfd.a), or will be GDB's remote fileio stat call. The fstat call you are looking at in gdb_bfd.c is I believe only used as part of GDB's internal caching mechanism for BFDs. I can't see anywhere that these mtime values can escape gdb_bfd.c, nor do I see anywhere that these values are compared to values returned by bfd_stat. We know that the value in reread_symbols comes from the system stat. So what I'm missing, is the path by which objfile::mtime gets set from anywhere other that within libbfd.a, such that it might get contaminated by a gnulib stat result. Thanks, Andrew