Failure with PR16566 new test on Mingw hosts

[Clément Chigot]

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.

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.

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[<strtab_count>].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.

Clément