From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 863483858284 for ; Wed, 24 May 2023 08:56:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 863483858284 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-64d3e5e5980so697690b3a.2 for ; Wed, 24 May 2023 01:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1684918593; x=1687510593; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HNr/bsI8Fe5JJUV71RF14kjaohLJd7yWhr2zOAo1WSA=; b=fyu8eRDuCWpKzc3n7hHUuKB+7xpMfi7pqVNDu15Ykx152d6sKD/LNmHNvkkpx40MbA tob3x4U/HJDqvQzE/ox3Dntc2WevaReaP0Tj1s2QbfmifzPRf7UiBl2nx8QtnhvKHYXf y+PBInuQkR8HqV2oZUVmNyWdWmszz7Z7Xy0ozEJbtWGAokXLUPxcr0N+ndRwQpvGmruD COwmoYouQ7JIew26KWNjuGRaa0XU5Dj68gScgkftumIOoJn9VR8vWFmPOytDhZSVaaj6 qv+kczNUUxWXDG8Xt2b5nxjbZSKV3EjdbgrPuTUQD600MyAORwBXAKiuRzFCOLDuT6Vv Me3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684918593; x=1687510593; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HNr/bsI8Fe5JJUV71RF14kjaohLJd7yWhr2zOAo1WSA=; b=No9IJa7wyoSF7Y80ygl5pySwR+bRPWqACzgw7eZdDFPBcsMj81FkzBQ7ngEZ9ldwpp /Ia6YGP6kvxFdMZdCvId5gO5rIPNNTarIoNYtaaQIP5vT/XhgT39CaD4BynK4yMW45hC qt8I5RgO2/o6zPlDgqtToCj0YOMwTvEijWiSpLTLRK7xdgqBkLDcKeKJexhcVXcY9jRk 5o7Bft7zLlgmGUstConXc6cU5rsMv1pwPCzqqdAxtqQPFF8didPw/glPx4z498bS5dOW feAuXzk5te/WDqOm9eTzySRMmulEAGDQQvq4bKOec4ocYALiYcTyz2jdzMi+AUiK1RXH U6aQ== X-Gm-Message-State: AC+VfDygHMrg+7d+9IIbB0T/S/O79ke99saovLjnMsjce7vAFjdX9+oJ lyBhRhVdYqIxDRKziOAdieqCceu55hJfGzbE0kQ1gg== X-Google-Smtp-Source: ACHHUZ6ciWXG8VEglsT5HJzZLPFvrbr/eUOmQvza4OQ364sOQ0+V8LE3Kn6VKS3H2qmEqGz4F2BcCNT3Ln3Q+J4KSDA= X-Received: by 2002:a17:902:ab5c:b0:1ad:cb4b:1d50 with SMTP id ij28-20020a170902ab5c00b001adcb4b1d50mr16156799plb.43.1684918593280; Wed, 24 May 2023 01:56:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Cl=C3=A9ment_Chigot?= Date: Wed, 24 May 2023 10:56:22 +0200 Message-ID: Subject: Re: Failure with PR16566 new test on Mingw hosts To: Alan Modra Cc: Nick Clifton , =?UTF-8?Q?Cl=C3=A9ment_Chigot_via_Binutils?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 2:07=E2=80=AFAM Alan Modra wrote= : > > On Tue, May 23, 2023 at 05:31:37PM +0200, Cl=C3=A9ment Chigot wrote: > > Hey Alan > > > > On Tue, May 23, 2023 at 3:11=E2=80=AFPM Alan Modra w= rote: > > > > > > On Tue, May 23, 2023 at 10:48:06AM +0200, Cl=C3=A9ment Chigot via Bin= utils 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 directio= n) > if (direction !=3D SEEK_CUR) > position +=3D offset; > > - if ((direction =3D=3D SEEK_CUR && position =3D=3D 0) > - || (direction =3D=3D SEEK_SET && (ufile_ptr) position =3D=3D abfd-= >where)) > - return 0; > - > result =3D abfd->iovec->bseek (abfd, position, direction); > if (result !=3D 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. 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. > > However, I'm not sure what that means. Is it possible to write/read a > > bfd without using bfd_fwrite, bfd_fread ? I didn't find any. But that > > would create a gap between the "where" field and the actual file > > pointer. > > Otherwise, we should probably enforce a fseek when the direction has > > changed. Even if Windows docs says that both fread and fwrite should > > update the file pointer something might be wrong here. > > https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-w= fopen > says fseek (or fsetpos or rewind) is necessary when changing from > reading to writing, and the same or fflush when reading after writing. > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html > says the same. > > > Another interesting thing I've discovered. The call to > > bfd_canonicalize_symtab allocates some contents for the strtab section > > header which is then written when the bfd is being closed. In > > elf.c:_bfd_elf_write_object_contents, i_shdrp[].contents > > is not anymore NULL. > > AFAICT, that part was already written before during the final link > > part. I'm not sure if it has any impact, we are probably writing the > > same stuff again. But I think it's worth mentioning it. > > Yes, I think it would be safer to close the output file and reopen for > lang_map if reporting local syms per section in the map is important. > > -- > Alan Modra > Australia Development Lab, IBM