Re: Failure with PR16566 new test on Mingw hosts

[Alan Modra <amodra@gmail.com>]

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.

> 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