From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id 526D93857711 for ; Wed, 24 May 2023 09:33:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 526D93857711 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-pg1-x52d.google.com with SMTP id 41be03b00d2f7-52c30fa5271so37489a12.0 for ; Wed, 24 May 2023 02:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684920829; x=1687512829; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=GhcVjNDGnAnkSK5NBrknibvW7RgfPdgMflX0i5n0+UY=; b=EJV/4AlsAtE5IJ5vt+pMJglisk2apKuT1IMyKd0NGAcWBBG3xDFoizdsuFCaNITSnJ fVefLWV4rFY1471iAmvn7ITBDwGriU9sC37JKn68doZ2QETrXYeHOxQHTNW0SLS5PovL z24q8rEswqc4w5n54PLd2pkwqJ8ccwfDVwFv8RsmnEQ/kFJeRL7jPZx/ygTa43JVf7A+ ZLscfJFQ6NCNMkI+qzO7N7imYq6neF405g2N2fjiuxSLY+wb9ID7I+dfzkF8yKExwFO2 eMW9KWOfReScjJ8NULoal8Leflq2x2IIhsUBgi+ZGrIFacNTfou5dRH/96ZtJv1jYux+ OV4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684920829; x=1687512829; h=in-reply-to:content-transfer-encoding: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=GhcVjNDGnAnkSK5NBrknibvW7RgfPdgMflX0i5n0+UY=; b=WdaRoTTXE3pVeAO0k7Z9uY/OJGNMlW9mPD8MNcqDq/Yc83XFsZdW+VC51nx+OAvBIm 01Zc0/uxOKpQLuROkr6hig4T8GPes6sDmrPmLH9Hm8AggHA36lnu1aL5OCzGkx+uXdN2 pWCQ+M2TKR0PZCeDleKGSL2DpzoM2l1uVmWW+kmqct+95QTA81aFnmFUgeqx8d57GUsM BVfBgbfO6EGf2UPlrzu3e7ghPFJI7ZC50fewWvo/SeOx4y4oOhtOx4eJzkWmoqcBlsPG 6PGpDdSH847FZMxxdjzdclX/pjMUdZqRAkQrpeTQVJhh4DyNNoZmibWL6PbTm5/W+Pmd zh7A== X-Gm-Message-State: AC+VfDwr6YUG72jMRdkUXsUVtwDuIkItv29Wr5Qwyil02W5/EfwBqZ10 N+3xmeHz5wYmYXacG4aYEWE= X-Google-Smtp-Source: ACHHUZ7+g+v/HYmLRyLpKeXRfM9n1BmuPONBSc4qP6LWB2Otgz99LEuTEDWRTYmKWC8x/AXRYyMf2Q== X-Received: by 2002:a17:902:778c:b0:1ae:5bd0:d452 with SMTP id o12-20020a170902778c00b001ae5bd0d452mr16505337pll.26.1684920829263; Wed, 24 May 2023 02:33:49 -0700 (PDT) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:4d08:cebd:d73f:b794]) by smtp.gmail.com with ESMTPSA id d6-20020a170902c18600b001addf547a6esm8289923pld.17.2023.05.24.02.33.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 May 2023 02:33:48 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id AECDF11411B5; Wed, 24 May 2023 19:03:45 +0930 (ACST) Date: Wed, 24 May 2023 19:03:45 +0930 From: Alan Modra To: =?iso-8859-1?Q?Cl=E9ment?= Chigot Cc: Nick Clifton , =?iso-8859-1?Q?Cl=E9ment?= Chigot via Binutils Subject: Re: Failure with PR16566 new test on Mingw hosts Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-3033.9 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 Wed, May 24, 2023 at 10:56:22AM +0200, Clément Chigot wrote: > On Wed, May 24, 2023 at 2:07 AM Alan Modra wrote: > > > > On Tue, May 23, 2023 at 05:31:37PM +0200, Clément Chigot wrote: > > > Hey Alan > > > > > > On Tue, May 23, 2023 at 3:11 PM Alan Modra wrote: > > > > > > > > On Tue, May 23, 2023 at 10:48:06AM +0200, Clément Chigot via Binutils wrote: > > > > > I don't know why but this seems to be triggered by the new call to > > > > > bfd_canonicalize_symtab introduced when we are logging the local > > > > > symbols [1]. > > > > > Any idea about what's going on ? > > > > > > > > The output file is opened "w+b". ldwrite() will cause some of the > > > > file to be written, but not all is output until bfd_close(). So > > > > reading the symbols means the file IO is write, read, write. Wild > > > > guess: no fseek or similar between changes in direction? bfd_seek > > > > doesn't call fseek if the file position doesn't move. > > > > > > Nice guess ! It seems to be the issue. Forcing a fseek is fixing it. > > > I have a quick workaround which resets the value of > > > "link_info.output_bfd->where" after the new bfd_canonicalize_symtab > > > call. > > > > The following is a better fix, I think. I didn't see much impact on > > "time make check" by doing this. > > > > diff --git a/bfd/bfdio.c b/bfd/bfdio.c > > index 75a3309c582..22c39a7b0cc 100644 > > --- a/bfd/bfdio.c > > +++ b/bfd/bfdio.c > > @@ -456,10 +456,6 @@ bfd_seek (bfd *abfd, file_ptr position, int direction) > > if (direction != SEEK_CUR) > > position += offset; > > > > - if ((direction == SEEK_CUR && position == 0) > > - || (direction == SEEK_SET && (ufile_ptr) position == abfd->where)) > > - return 0; > > - > > result = abfd->iovec->bseek (abfd, position, direction); > > if (result != 0) > > { > > That was my first fix too, but I thought it would have reduced the > performance too much. If you say that it looks ok then fine. > Do you think it makes sense to wrap it by a #ifdef __WIN32 ? Linux > (and probably other Unix) doesn't have the issue. No, it could well be a unix problem too. > I'm also wondering if by removing this code, we could not remove > "abfd->where" as well. It looks like its first aim was to mimic the > file pointer. But if we force a fseek for every fwrite/fread we might > not have needs of it anymore. I think we might need abfd->where for cache.c closing and reopening of files, so that reads and writes continue on from the same file position as if the file was not closed. -- Alan Modra Australia Development Lab, IBM