This is the mail archive of the
mailing list for the GCC project.
Re: X18 on AArch64
- From: pinskia at gmail dot com
- To: AndrÃ Hentschel <nerv at dawncrow dot de>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 8 Jul 2015 11:59:40 -0700
- Subject: Re: X18 on AArch64
- Authentication-results: sourceware.org; auth=none
- References: <559C36CD dot 5060304 at dawncrow dot de> <9B26B3F4-D11B-41DE-809E-C19DA7A17090 at gmail dot com> <559D6E48 dot 9070903 at dawncrow dot de>
> On Jul 8, 2015, at 11:39 AM, AndrÃ Hentschel <email@example.com> wrote:
>> Am 07.07.2015 um 23:01 schrieb firstname.lastname@example.org:
>> What does the elf abi say about x18, I thought it was just another temp. If the target does not use it as a platform reg. Note there are many assembly files which might use x18 also due to that.
>> So this means you need wrapper functions when moving between the different abis. Nothing much can be done in gcc really. Please push this back to wine instead.
>> Also I think windows had a bad choice of using x18 when there was a system register already for tls.
> I guess i haven't explained the problem too good.
> The problem already starts with Wines environment which includes things we can't do something about like the loader/dynamic linker...
> Using wrapper functions in Wine is not feasible, that'd be a massive infrastructure change to huge and old codebase, would need a lot of work
> and in the end won't get upstream.
So what. Changing gcc and distros for one specific thing would be a step backwards. Changing wine to better support huge differences in abi would be better.
> What's needed is, is that distributions don't use x18 by default, so we need a good patch for that, hence i ask for a usable chain register (X8-X15?)
I think this is a bad idea because it would mean old code will no longer work.
> Truly it would be better to upstream that to gcc, but I don't have much hope left.
> For the ELF ABI thing, i didn't found specific calling conventions or register usage description in it...
It is part of the aacps calling convention that arm provides.
> For the windows thing, good choices are not part of their development process ;)