[Bug target/108866] Allow to pass Windows resource file (.rc) as input to gcc

["pali at kernel dot org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866

--- Comment #8 from Pali Rohár <pali at kernel dot org> ---
Thank you for input, as you already figured out there is lot of work for this.
And I think I'm not skilled enough to implement everything properly, so I would
have to let this to gcc developers. I will answer questions:

> 1) should gcc pass through any arguments to windres?
>  -I --include-dir=<dir>       Include directory when preprocessing rc file
>  -D --define <sym>[=<val>]    Define SYM when preprocessing rc file
>  -U --undefine <sym>          Undefine SYM when preprocessing rc file

windres's -I -D and -U are used for when processing "rc" file. So yes, gcc
should propagate -I -D and -U to windres for "rc" files (but not to "res"
files).

> 2) does -m32 or -m64 need handling in any specific ways?

This is really a good question and I totally forgot about this. Because gcc's
-m32 generates coff for different arch that gcc's -m64, it means that -m32/-m64
switches has to be propagated to windres. I think that gcc's -m32 and -m64
should be "converted" to windres's --target= option (with the correct
argument).

> 3) the linker has -Wl, for passing arguments to it, does windres need an equivalent?

I think that it is not needed at all because all windres's flags should already
have some options in gcc.

> 4) windres --help says:
> FORMAT is one of rc, res, or coff, and is deduced from the file name
> should ".res" be handled too?

"rc" is text resource format, "res" is the binary resource format. "coff" is
PE/COFF object file format with binary resource.

windres has option -J which explicitly sets the input format (and then
extension is not used for deduction).

So I think that gcc driver should have rules for both text (rc) and binary
(res) formats. And in my "test.spec" experiment are rules for both formats.


> 5) windres --help has this list of "supported targets":
> x86_64-w64-mingw32-windres: supported targets: pe-x86-64 pei-x86-64 pe-bigobj-x86-64 elf64-x86-64 pe-i386 pei-i386 elf32-i386 elf32-iamcu elf64-little elf64-big elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex plugin
> 
> Do they matter? I did not expect to see any "elf" on this list, because windows obviously doesn't use it.

This is for sure bug. ELF does not support embedding windows resource files.
Windows resources can be embedded only into PE/COFF image file or into PE/COFF
object file.

And AFAIK, windres supports parsing both PE/COFF image and object files, but
can generate only PE/COFF object file.

So windres target list for sure contains non-senses and that is also reason why
you got those errors when you specified ELF.

> 6) does llvm-windres need to be considered at all? should there be a way to select it? an -fuse-rc= command option or so?

GNU windres is part of the binutils, where is also GNU as. So if the gcc is
using GNU as from binutils for assembling then it should use also GNU windres
from binutils for processing resources.

So in my own opinion, usage of "windres" from gcc should be handled in the same
way as usage of "as" from gcc. If gcc has a way to specify its own as binary,
then it makes sense to allow specifying its own windres binary.

But gcc developers can have different opinion.