[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #41 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #36 from Daniel Santos <daniel.santos at pobox dot com> ---
> Thank you for all of your work on this.  The .cfi directives shouldn't be *too*
> critical -- I've barely scratched the surface of learning DWARF and, iirc, the
> last time I stepped through these stubs in gdb it still wasn't always able to
> determine the call frame correctly (although I could be thinking of stepping
> through the assembly code in the test program).  I suppose this can be an issue
> for somebody debugging Wine code at some future date, but I have no qualms with
> removing it for now, and possibly redoing it later in more portable way (and
> that actually provides the debugger with everything it needs).

I'd just leave them in as comments for now as a reminder, similar to
what's done in libffi.

> Also, you *had* mentioned this linking problem in the past and I apologize for
> loosing track of it.  I have not actually done a thorough study of ABIs used in
> other *nix operating systems, but my guess would be that all 64-bit platforms
> that GCC supports use the SystemV ABI except for Windows (Cygwin & MinGW)? 
> This is a question outside of my expertise, so please let me know if the below
> solution amenable.

I guess that's true for most x86_64 Unix systems, but I'm unsure about
Darwin here, as well as non-Unix x86_64 targets.  One difference I
noticed during my Darwin testing last night was a __USER_LABEL_PREFIX__
of _, which your code doesn't yet account for.  I managed to put
something together, based on your original v5 patch, and the result did
compile on Darwin.  However, all ms-sysv.exp execution tests FAIL there;
had no time to investigate yet.  Might indicate a bug in my changes or
an ABI difference.

> I should also note that while this optimization isn't meant for Windows and
> would likely almost never appear in code built for windows (unless somebody is
> trying to link to objects/libs built on for *nix), support on Windows is
> explicitly disabled due to the SEH unwind emit code not supporting
> REG_CFA_EXPRESSION, which it requires.  So we don't need the stubs on Windows
> anyway.
>
> diff --git a/libgcc/config.host b/libgcc/config.host
> index 7711abf2704..f0f0d6c0916 100644
> --- a/libgcc/config.host
> +++ b/libgcc/config.host
> @@ -1355,6 +1355,14 @@ esac
>  case ${host} in
>  i[34567]86-*-* | x86_64-*-*)
>         case ${host} in
> +       *-*-cygwin* | *-*-mingw*)
> +               ;;
> +       *)
> +               tmake_file="${tmake_file} i386/t-msabi"
> +               ;;
> +       esac
> +
> +       case ${host} in
>         *-musl*)
>                 tmake_file="${tmake_file} i386/t-cpuinfo-static"
>                 ;;
> @@ -1365,11 +1373,12 @@ i[34567]86-*-* | x86_64-*-*)
>         ;;
>  esac
>
> +
>  case ${host} in
>  i[34567]86-*-linux* | x86_64-*-linux* | \
>    i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | \
>    i[34567]86-*-gnu*)
> -       tmake_file="${tmake_file} t-tls i386/t-linux i386/t-msabi
> t-slibgcc-libgcc"
> +       tmake_file="${tmake_file} t-tls i386/t-linux t-slibgcc-libgcc"
>         if test "$libgcc_cv_cfi" = "yes"; then
>                 tmake_file="${tmake_file} t-stack i386/t-stack-i386"
>         fi

Seems the right thing to do.  In my patch, I'd added t-msabi to
Darwin/x86 and Solaris/x86 only, but unless the testsuite is changed to
exercise the code on every x86 target, your change is certainly consistent.

> As for the stubs, I don't think there's a real need to stay tied to gas
> extensions -- truth be told, this was my first actual non-inline, x86 assembly
> code I have written (last time I did assembly prior was on a Motorola
> 6502/6510), so I'm sorry to have forced you to become my unwitting tutor!  :) 
> This is assembly with cpp, so the gas .macro could be replaced with a cpp
> macro, but is that acceptable considering that it would result in multiple
> instructions on the same line delimited by semicolons instead of "\n\t"?  So
> should I just copy & paste the instructions and be done with it?

My patch of last night went for the cpp macro route: as you say, we
already use cpp features and doing so here makes the code easier to read
and less error-prone.

I'm attaching both my testsuite changes to deal with
__USER_LABEL_PREFIX__ (shamelessly stolen from libffi resp. a testcase
that has a similar need), which is enough to allow the code to compile
and link on Darwin, and the libgcc parts.

I haven't yet tried merging those changes with you v5.1 patch, though.

        Rainer