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
