From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 9F2523858CDA for ; Mon, 10 Jul 2023 23:17:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9F2523858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1b8bbcfd89aso25154795ad.1 for ; Mon, 10 Jul 2023 16:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689031058; x=1691623058; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=bzvm3r3cEpYcsN7uHFwZqfnlhKCpj/xXXcdWYHSmP0o=; b=rb/fSR41GWuiRLsA1RynBxs1WQ8CAqlJTD6nvPXihJ7sOU7HiEZr2FuA2ngFICnNgz ZozFX6b5nCabiZephYxbQq+0X0M7uFZH1iFpTNyEMLSu0AAnd6UA7j5tEdwuJxzMFdTz qbZ+bnm4kXplpmFmZuPBVn+dx5AhyP2Vb1oMronmnecYbqtn8YXFMI1sBx6mJQI0refx LarMYrAGFBWk4wOpwDlDu7GIZQF7OSEwwaWPUVhqO45xX6QHELX8MTWn7x19SNZ98pR5 YTXg68/EE6xwrhI/pIUYu4Pc3md3ETv/8zAoLEdTJUzq5Aenw7QMbf40TqZP+Djs+f7p MOHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689031058; x=1691623058; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bzvm3r3cEpYcsN7uHFwZqfnlhKCpj/xXXcdWYHSmP0o=; b=VRqHIe3CkKdgHl0HlywWgmvRYJL7PMr1R4SH5iBO5qBg+4B1i1gVUPurifV7BMNRVG YFFT9e83DtE07HiXGG09FJEPddhHedpUG2/PGexkcqLOq/dhzDyrN6WK2XoQjTuKNKm0 irYGeqgbrg9IXujDheB2tCC9xoIfZb1Ss3c1gQ66t3DEFDZt9g+LfHS1ni16nw2ldh46 m8PHGGcioPQYvxVN9ssfl6DmQ/RM00TrMMQ7km9eP4TRl9wgKH7sTif+ChZY+PFghIk2 8u+HQQwtv/I0uGqR1Yr8/cQy9AkLgbX5f1yFwCweku4s8J6epjSneKxAXZXdq3A6tooD PhMg== X-Gm-Message-State: ABy/qLb1MZAyjdhnMTDUzXaVKpLZxFaVzWWjwwYD1Ak0Rb0Suv116RqF ykvaKv2mrh3s87WohVYeB9A= X-Google-Smtp-Source: APBJJlE8LIA5TJKPYp2g9TJpfilC+ofdBRy6KLF/Qnz22/ZNI3VIM4Kf9Gq97rpX8oLD38/mmc+Vnw== X-Received: by 2002:a17:902:e80d:b0:1b8:b436:bef3 with SMTP id u13-20020a170902e80d00b001b8b436bef3mr12618571plg.24.1689031058558; Mon, 10 Jul 2023 16:17:38 -0700 (PDT) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:1e19:26f8:45b5:14e6]) by smtp.gmail.com with ESMTPSA id jd10-20020a170903260a00b001b850c9af71sm404293plb.285.2023.07.10.16.17.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jul 2023 16:17:37 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 148D311414ED; Tue, 11 Jul 2023 08:47:35 +0930 (ACST) Date: Tue, 11 Jul 2023 08:47:35 +0930 From: Alan Modra To: Tom Tromey Cc: Aditya Kamath1 via Gdb-patches , Ulrich Weigand , Aditya Kamath1 , Alan Modra , Sangamesh Mallayya Subject: Re: [Patch] Fix AIX shared library load broken during fork (). Message-ID: References: <87zg43rc2f.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zg43rc2f.fsf@tromey.com> X-Spam-Status: No, score=-3033.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On Mon, Jul 10, 2023 at 10:00:40AM -0600, Tom Tromey wrote: > >>>>> Aditya Kamath1 via Gdb-patches writes: > > > +std::vector object_bfd_vector; > > I think it's a mistake to add a new global like this. > It seems to me that this would interact poorly with multi-inferior or > multi-target debugging. > > Also, since nothing ever clears the vector, these BFDs will never be > closed. The proper place to fix this of course is in bfd. Aditya, I think the following ought to cure the problem you're seeing. Did you open a PR? * coff-rs6000.c (add_range): Revise comment, noting possible fail. (_bfd_xcoff_openr_next_archived_file): Start with clean ranges. diff --git a/bfd/coff-rs6000.c b/bfd/coff-rs6000.c index 271a24fff69..59b9743356f 100644 --- a/bfd/coff-rs6000.c +++ b/bfd/coff-rs6000.c @@ -1598,14 +1598,21 @@ _bfd_xcoff_archive_p (bfd *abfd) /* Track file ranges occupied by elements. Add [START,END) to the list of ranges and return TRUE if there is no overlap between the - new and any other element or the archive file header. Note that - this would seem to preclude calling _bfd_get_elt_at_filepos twice - for the same element, but we won't get to _bfd_xcoff_read_ar_hdr if - an element is read more than once. See _bfd_get_elt_at_filepos use - of _bfd_look_for_bfd_in_cache. Also, the xcoff archive code + new and any other element or the archive file header. This relies + on _bfd_xcoff_read_ar_hdr not being called more than once for the + same element, but that should be true (*). The xcoff archive code doesn't call _bfd_read_ar_hdr when reading the armap, nor does it need to use extended name tables. So those other routines in - archive.c that call _bfd_read_ar_hdr are unused. */ + archive.c that call _bfd_read_ar_hdr are unused. + + *) There is one case where this might fail, but I think it is + sufficently unusual that it doesn't seem worth fixing: When + scanning over archive elements using openr_next_archived_file, if + openr_next_archived_file is called twice with the same arguments + *and* the element returned is bfd_close'd between those calls then + we'll return false here. The _bfd_look_for_bfd_in_cache use in + _bfd_get_elt_at_filepos stops this happening in the case where an + element is not closed. */ static bool add_range (bfd *abfd, ufile_ptr start, ufile_ptr end) @@ -1770,12 +1777,14 @@ _bfd_xcoff_openr_next_archived_file (bfd *archive, bfd *last_file) { if (last_file == NULL) { + /* If we are scanning over elements twice in an open archive, + which can happen in gdb after a fork, ensure we start the + second scan with clean ranges. */ + x_artdata (archive)->ranges.start = 0; + x_artdata (archive)->ranges.end = SIZEOF_AR_FILE_HDR; + x_artdata (archive)->ranges.next = NULL; + x_artdata (archive)->ar_hdr_size = SIZEOF_AR_HDR; filestart = bfd_ardata (archive)->first_file_filepos; - if (x_artdata (archive)->ar_hdr_size == 0) - { - x_artdata (archive)->ranges.end = SIZEOF_AR_FILE_HDR; - x_artdata (archive)->ar_hdr_size = SIZEOF_AR_HDR; - } } else GET_VALUE_IN_FIELD (filestart, arch_xhdr (last_file)->nextoff, 10); @@ -1794,12 +1803,11 @@ _bfd_xcoff_openr_next_archived_file (bfd *archive, bfd *last_file) { if (last_file == NULL) { + x_artdata (archive)->ranges.start = 0; + x_artdata (archive)->ranges.end = SIZEOF_AR_FILE_HDR_BIG; + x_artdata (archive)->ranges.next = NULL; + x_artdata (archive)->ar_hdr_size = SIZEOF_AR_HDR_BIG; filestart = bfd_ardata (archive)->first_file_filepos; - if (x_artdata (archive)->ar_hdr_size == 0) - { - x_artdata (archive)->ranges.end = SIZEOF_AR_FILE_HDR_BIG; - x_artdata (archive)->ar_hdr_size = SIZEOF_AR_HDR_BIG; - } } else GET_VALUE_IN_FIELD (filestart, arch_xhdr_big (last_file)->nextoff, 10); -- Alan Modra Australia Development Lab, IBM