GCC - updates

[KO Myung-Hun]

This has passed my regression test.

Thanks a lot!

[Paul Smedley]

Thanks for testing KO! Promise I've get around to figuring out  why 'gcc -Zexe test.c' produces a.exe not test.exe soon. I know this behaviour kinda matches *nix behaviour (where a.out) is produced, but it is a regression from earlier OS/2 ports.

[Steven Levine]

The reason that gcc with a -o option generates a.exe is because an incorrect value is being passed to the specs processing code for the link options.  To dump a copy of the specs, use

  gcc -dumpspecs >gcc1420.specs

The gory details of spec file syntax is at

  https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html

To see how gcc is processing the specs, use something like

 gcc -v tmp.c

where tmp.c is minimal c program.  I used

  g++ -t -t v xcpt.cpp

because it was handy.  The g++ output includes

COLLECT_GCC_OPTIONS='-pipe' '-v' '-t' '-t' '-mtune=generic' '-march=i686' '-dumpdir' 'a.'
 ld.exe -o a.exe -t -t /@unixroot/usr/lib/crt0.o -LD:/usr2/local1420/bin/../lib/gcc/i686-pc-os2-emx/14 -LD:/usr2/local1420/bin/../lib/gcc -LD:/USR2/LOCAL1420/lib -L. -LD:/usr2/local1420/bin/../lib/gcc/i686-pc-os2-emx/14/../../.. -L/@unixroot/usr/lib E:\TMP/ccc6HJA2.o -lstdc++ -lm -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2

which is consistent with the symptoms.  Note that the COLLECT_GCC_OPTIONS value for 9.2.0 omits the -dumpdir option, but this has no effect on the -o logic.

The -o is generated by the part of the *link: action that reads

 %{!o*:-o %b%{Zdll|shared:.dll}%{!Zdll:%{!shared:%{!Zexe:.exe}}}}

which says if there is no explict -o switch use the value of the %b variable to build the executable name.

What we need to do is track down where %b is set and figure out why it defaults to "a" in 14.2.0.  I suspect a lost patch since gcc on other plaforms is going to default the executable name to a.out.

FWIW, -t -t option sequence in my testcase has no effect here since emxomfld is not used.

[Paul Smedley]

Thanks Steven! I have a set of diffs of bww 9.2.0 vs the original code that I plan to comb through to identify deltas with my code.

Now that exception support is working with 14.2.0 this has made it a bit higher up the list

[Steven Levine]

The %b substitution is at

gcc\gcc.cc:6161
     case 'b':
       /* Don't use %b in the linker command.  */
#ifndef __OS2__ /* this causes 'internal compiler error: in do_spec_1, at gcc.c:6063' with GCC 11.x - dunno why - FIXME */
       gcc_assert (suffixed_basename_length);
#endif
       if (!this_is_output_file && dumpdir_length)
         obstack_grow (&obstack, dumpdir, dumpdir_length);
       if (this_is_output_file || !outbase_length)
         obstack_grow (&obstack, input_basename, basename_length);
       else
         obstack_grow (&obstack, outbase, outbase_length);

We don't have source debug in this part of the code, but I can see the incorrect insertion into the obstack.  This is probably the dumpdir value.  The specs docs imply that we need a %w to have this_is_output_file set.

I'm thinking that if outbase is set correctly, editing the built-in specs to add a %w before the %b might be the fix.

For 9.2.0, the code is quite different.

gcc\gcc.c:5333
     case 'b':
       if (save_temps_length)
         obstack_grow (&obstack, save_temps_prefix, save_temps_length);
       else
         obstack_grow (&obstack, input_basename, basename_length);
       if (compare_debug < 0)
         obstack_grow (&obstack, ".gk", 3);
       arg_going = 1;
       break;

Hopefully, this will save you some time.

[Paul Smedley]

Thanks Steven..

I updated LINK_SPEC to:

Code: [Select]

#define LINK_SPEC                                                              \
  "%{Zexe} %{Zstack*} %{Zlinker*} %{Zmap*} %{Zsym} %{Zdll} %{shared:-Zdll} %{static:-static} " \
  "%{!o*:-o %w%b%{Zdll|shared:.dll}%{!Zdll:%{!shared:%{!Zexe:.exe}}}} "          \
  "%{static:%{Zcrtdll*:%e-static and -Zcrtdll are incompatible}}"              \
  "%{Zomf:%{Zaout:%e-Zomf and -Zaout are incompatible}}"                       \
  "%{Zdll:%{Zexe:%e-Zdll and -Zexe are incompatible}}"                         \
  "%{shared:%{Zexe:%e-shared and -Zexe are incompatible}}"                     \
  "%{Zsmall-conv:%{Zcrtdll*:%e-Zsmall-conv and -Zcrtdll are incompatible}}"

But now I get

Code: [Select]

{0}[u:\dev\gcc-os2-14.x] gcc -Zexe helloworld.c
ld.exe: No such file or directory for .exe
Assertion failed: crumb->x.used.size <= crate->crumb_size, file ./libc-0.1.12/src/emx/src/lib/malloc/ifree.c, line 65

and sure enough adding -t -t gives:

Code: [Select]

Invoking emxbind: emxbind -bq -o .exe C:\var\temp/ccgEvumKldXXXXXX
ld.exe: No such file or directory for .exe


[Dave Yeo]

What about without -Zexe? -Zexe exists only to work around makefiles that don't know about exeext or .exe, so not only foo gets built but also foo.exe. Starting with GCC 2.9.x foo became an executable stub pointing to foo.exe.
Should almost never need it now.

[Steven Levine]

FWIW, running

  gcc -v -Zexe helloworld.c

will give better debugging output for this issue.

Also, it occurs to me that rather than rebuilds gcc, we can experiment with the specs by running

  gcc -specs=my.specs -v -Zexe helloworld.c

where my.specs is the edited output of

  gcc -dumpspecs >my.specs

I'll experiment with this and see what is revealed.

The missing basename implies that for:

gcc\gcc.cc:6168
       if (this_is_output_file || !outbase_length)
         obstack_grow (&obstack, input_basename, basename_length);
       else
         obstack_grow (&obstack, outbase, outbase_length);

neither input_basename or outbase is getting set.  This is unexpected since it appears that in 9.2.0 input_basename was
providing the value for %b.

[Paul Smedley]

It's interesting - at https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/gcc.cc#L8196 suffixed_basename_length has been set (in the case of helloworld.c to 12)  but by https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/gcc.cc#L6291 it's 0.

Weird.

the positive is that if I set '  suffixed_basename_length = 10;' at L6291 then we do get a valid helloworld.exe....

[Paul Smedley]

OK suffixed_basename_length is being reset to 0 here - https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/gcc.cc#L9319

I'm thinking in hindsignt that the comment at https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/gcc.cc#L6289 "Don't use %b in the linker command" is perhaps a sign that for whatever reason,  we should not be using %b in the linker command - which we clearly are at https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/config/i386/emx.h#L447

So... we need to re-think how to get the output file name to match the source file name - or accept that we match the defaults on other OS....

[KO Myung-Hun]

Hi/2.

I've fixed and attached the patch.

This is based on 13.3.0. But I think there will be no problem to apply to 14.2.0 tree.

Thanks!

[Paul Smedley]

Thanks - this does work - however I still need the hack at https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/gcc.cc#L6290

Edit: haiku had similar issues with %b in LINK_SPEC  - https://discuss.haiku-os.org/t/my-haiku-arm-uefi-port-progress/10736/116?page=6

[KO Myung-Hun]

I think gcc_assert() is intentional to prohibit to use `%b' and/or `%B' in linker command. The comment is for gcc_assert() line.

In future, it would be better to drop to use `%b' on OS/2, too.

`a.exe' vs `name.exe' is not the show stopper.

Thanks!

[Paul Smedley]

binutils 2.43.1 - lightly tested - https://smedley.id.au/tmp/binutils-2.43.1-os2-20240819.zip