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

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

[pali at kernel dot org]

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

            Bug ID: 108866
           Summary: Allow to pass Windows resource file (.rc) as input to
                    gcc
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pali at kernel dot org
  Target Milestone: ---

Currently it is possible to pass source C file, source assembler file, object
file, library to gcc as an input argument and gcc calls needed tools to compile
and link all input files to one output binary.

But gcc currently is not able to recognize Windows resource text file .rc when
it is passed as input argument. See:

$ x86_64-w64-mingw32-gcc test-rsrc.rc
/usr/bin/x86_64-w64-mingw32-ld:test-rsrc.rc: file format not recognized;
treating as linker script
/usr/bin/x86_64-w64-mingw32-ld:test-rsrc.rc:1: syntax error
collect2: error: ld returned 1 exit status

Currently resource file first needs to be passed to windres compiler and then
output object file from windres can be specified as input argument to gcc:

$ x86_64-w64-mingw32-windres --input-format=rc --output-format=coff
--input=test-rsrc.rc --output=test-rsrc.o

It would be nice if gcc is able to call windres automatically for resource text
file, like for assembler source, for generating object file.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The target code could add driver specs to let the gcc driver understand what
.rc is.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

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

[pali at kernel dot org]

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

--- Comment #2 from Pali Rohár <pali at kernel dot org> ---
Andrew, I do not know what is gcc driver nor what to do for it. But if you can
show me some pointers, I can try it.

Or if you need more details about files, usage, etc... please let me know.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-03-13
             Status|UNCONFIRMED                 |NEW

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Pali Rohár from comment #2)
> Andrew, I do not know what is gcc driver nor what to do for it. But if you
> can show me some pointers, I can try it.
> 
> Or if you need more details about files, usage, etc... please let me know.

See gcc.cc (default_compilers).
It contains a mapping from suffix to language and language and how to
"compile/assemble" the files.

See also */lang-specs.h which are included via specs.h (specs.h is a generated
file while building, see the makefile there and depends on which language is
enabled).

Most likely you would add a new target macro which adds to that part of the
gcc.cc and define that macro in the mingw headers.

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

[amonakov at gcc dot gnu.org]

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

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amonakov at gcc dot gnu.org

--- Comment #4 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
It's possible to tinker with spec strings without rebuilding the compiler, see
this blog post by Geoff Wozniak (which supplies links to formal docs):
https://wozniak.ca/blog/2024/01/02/1/index.html

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

[pali at kernel dot org]

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

--- Comment #5 from Pali Rohár <pali at kernel dot org> ---
Thank you for info, I read that blog post and based on those details I adjusted
spec file

$ x86_64-w64-mingw32-gcc -dumpspecs > test.spec

by adding additional lines to test.spec:

.rc:
x86_64-w64-mingw32-windres -J rc -O coff -i %i %{c:%W{o*}%{!o*:-o
%w%b%O}}%{!c:-o %d%w%u%O}

.res:
x86_64-w64-mingw32-windres -J res -O coff -i %i %{c:%W{o*}%{!o*:-o
%w%b%O}}%{!c:-o %d%w%u%O}


rc files contains resources in text format and res files in binary format.

With these changes x86_64-w64-mingw32-gcc was able to take both .c and .rc file
on the input and produce .exe file with resource.

$ cat test.c
int main() { return 0; }

$ cat test.rc
1 VERSIONINFO
BEGIN
END

$ x86_64-w64-mingw32-gcc -specs=test.spec test.c test.rc -o test.exe


Now show resource stored in test.exe:

$ x86_64-w64-mingw32-windres -O rc test.exe /dev/stdout

/* Type: version

   Name: 1.  */
LANGUAGE 9, 1

1 VERSIONINFO
BEGIN
END


Also replacing text test.rc file by binary test.res file works.


There is one problem with it. I had to "hardcode" x86_64-w64-mingw32-windres
name instead of just "windres". How to declare cross compile prefix? Because
gcc somehow for "as" automatically adds it as in spec file is just "as", not
"x86_64-w64-mingw32-as".

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

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Pali Rohár from comment #5)
> There is one problem with it. I had to "hardcode" x86_64-w64-mingw32-windres
> name instead of just "windres". How to declare cross compile prefix? Because
> gcc somehow for "as" automatically adds it as in spec file is just "as", not
> "x86_64-w64-mingw32-as".

See find_a_program in gcc.cc which detects special program names and then does
the transformation for them.
I suspect you should be able to add windres there in a similar way as dsymutil
(which IIRC is only used for darwin currently).

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

[peter0x44 at disroot dot org]

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

peter0x44 at disroot dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peter0x44 at disroot dot org

--- Comment #7 from peter0x44 at disroot dot org ---
I'm interested in this feature, and would use it if it worked.
I do have a few questions about how this needs to be implemented, though.

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

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

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

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

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.
I suspect some of these are not used/broken/handled by anyone, for windres
anyway. I tried the following:

$ x86_64-w64-mingw32-windres --target="elf64-x86-64" -i test.rc -o test.o
x86_64-w64-mingw32-windres: can't get BFD_RELOC_RVA relocation type: cause of
error unknown
$ x86_64-w64-mingw32-windres --target="elf32-i386" -i test.rc -o test.o
x86_64-w64-mingw32-windres: bruh.o: unsupported relocation type: 0x3f
$ x86_64-w64-mingw32-windres --target="elf32-iamcu" -i test.rc -o test.o
x86_64-w64-mingw32-windres: bfd_set_arch_mach(i386): cause of error unknown

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?

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

[pali at kernel dot 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.

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

[pali at kernel dot org]

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

--- Comment #9 from Pali Rohár <pali at kernel dot org> ---
(In reply to peter0x44 from comment #7)
> 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

I reported this particular issue into the binutils bugzilla:
https://sourceware.org/bugzilla/show_bug.cgi?id=31543