Mail Archives: cygwin/2018/11/29/11:34:18
--6zipuvUKAEymKn2g
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Nov 29 10:18, Sam Habiel wrote:
> On Thu, Nov 29, 2018 at 3:58 AM Corinna Vinschen wrote:
> > On Nov 28 11:06, Sam Habiel wrote:
> > > On Wed, Nov 28, 2018 at 11:01 AM Yaakov Selkowitz wrote:
> > > > On Mon, 2018-11-26 at 14:07 -0500, Sam Habiel wrote:
> > > > > [...]
> > > > > GT.M contains a large
> > > > > amount of assembly code, written to run on the x32 Linux ABI and =
the
> > > > > AMD x64 ABI. It's was very easy to get the x32 Linux ABI to run on
> > > > > Cygwin x32; Cygwin x64 on the other hand uses the Windows x64 ABI,
> > > > > which is very different than the AMD ABI (more detail here:
> > > > > https://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x8=
6-64/).
> > > > > I don't have the expertise nor the time to rewrite a lot of assem=
bly
> > > > > code to use the Windows x64 ABI. There are about 100 source code =
files
> > > > > that are in assembly.
> > > >
> > > > -mabi=3Dsysv ?
> > > >
> > > Are you telling me that gcc has a flag to support AMD ABI on Cygwin
> > > x64? The assembly code is not standalone; it gets called from C code
> > > and calls C code.
> >
> > That's what he's telling you. However, you have to interact with the MS
> > ABI(*) as well as soon as you call external library functions so it
> > makes sense to keep your C code in MS ABI. For the assembler functions,
> > you can just tell the compiler they are in SYSV ABI by adding a function
> > attribute to the declaration:
> >
> > int asm_func (args) __attribute__ ((sysv_abi))
> >
> > Good luck,
> > Corinna
> >
> > (*) Just keep in mind that Cygwin is LP64, not LLP64:
> > https://cygwin.com/faq/faq.html#faq.programming.64bitporting
> > [...]
> [...]
> This sounds very promising, but I would like a clarification; because
> I think you covered 50% of the issue:
>=20
> 1. There are frequent calls from the C code to Assembly.
> 2. There are also frequent calls from Assembly to C code.
>=20
> Looks like compiling the .s files with the -mabi=3Dsysv flag and
> declaring the function in C with the __attribute__ ((sysv_abi)) will
> fix #1.
You shouldn't have to use the flag when building the assembler files,
they are using SYSV ABI anyway. In fact, while Yaakov is right,
basically, I think in your scenario you should only use the GCC function
attribute since that allows more fine-grained control. Just stick to MS
ABI by default and only perform the SYSV ABI juggle where required to
interact with the assembler code.
> How about #2? I don't see an easy solution. The assembly code puts
> together the parameters in the registers in the sysv way (rdi, rsi,
> rdx, rcx, r8, r9), not rcx, rdx, r8, and r9.
One way is to create a SYSV wrapper for each C function called from
assembler. Assuming this simple scenario:
There's a C function foo(), which is called from assembler as
well as from other C functions.
extern long foo (long, double, int, long);
For the "normal" (i.e. MS ABI) C code add this in front of the above
declaration:
#define foo(a,b,c,d) __foo((a),(b),(c),(d))
So the C function is renamed to __foo and C code will call __foo.
Add a wrapper C file to add a function foo with SYSV ABI, calling
__foo:
#undef foo
long __attribute__ ((sysv_abi))
foo (long a, double b, int c, long d)
{
return __foo (a,b,c,d);
}
That should do it. Of course there may be more complicated cases,
but I leave them as excercise for the reader, and only you are in
a position to know them ;)
HTH,
Corinna
--=20
Corinna Vinschen
Cygwin Maintainer
--6zipuvUKAEymKn2g
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlwAFNcACgkQ9TYGna5E
T6CInA//SCOijJCTfjy56LxWtKk3bk6lUlmHuVd0eM9ht7L5gVVD6ICTu1bdB92z
Q0+KZF+S7Itg/KZAlGgCY+IhUcpP8IfRfD7CoQmy2/BjsdPVAFPpBbCDG0VlpmMG
4IYE7kjAd2nwb6xCKZVi0Yt6MCUJTEmq1Y0biR1qBzd7uL/2yl8YfdQkiZ+Y9Ko+
14BJQIGSCITUcUdowxQWbP3kxSGXXEo+r44ot7prdwW0HeJfv/6mow5uzQfx9Bpo
Zhj9SxQ79QVaV8h8fLA5yp2PGhvcbuOiVhlzbtHdnJquHQw6eyqzmeVce52eo8VJ
TLzuLYeQIk15klaVaQpIZleXrpVspdY1yuBgtLebYzoG4GeyVxShU/rGsNejRHw+
9MdACOrZ0nbxAHucRQxWPZMTyOiNHcL9LC1ZM5CA9QRuMIcN8FHbRleikhnbNYui
Qi8pfFSIxg2icQkSCIyc/J4OWx1d5ZUPaAAmGhtzfwwQgmTfTBqwnXfHrGuXzjdI
Jo25WiNdWLaT4rSJIs4k7O077p8t2e6WdKZ1G74k92CTsU+7Lu151EWtfS23Wf40
dmUELMuDwk2S3j/pElGUyJ8hTjDLkWrSONihoBRGgKxl8S6+8x0YXM2uNsXNCy3i
fYSTaJMKVIFoy9GhNVpNeKuP6aKPNTd/FLTEmPuTrBOZtvnLnMU=
=fyQo
-----END PGP SIGNATURE-----
--6zipuvUKAEymKn2g--
- Raw text -