Failure with PR16566 new test on Mingw hosts

[Clément Chigot]

On Wed, May 24, 2023 at 11:33 AM Alan Modra <amodra@gmail.com> wrote:
>
> 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 <amodra@gmail.com> 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 <amodra@gmail.com> 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.

Indeed.
Thanks for the patch anyway.

> > 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.

Alright, better keep it as is then.