This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ARM inline assembly usage in Linux kernel
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Pinski <pinskia at gmail dot com>
- Cc: Renato Golin <renato dot golin at linaro dot org>, Saleem Abdulrasool <compnerd at compnerd dot org>, GCC Mailing List <gcc at gcc dot gnu dot org>, Richard Sandiford <rsandifo at linux dot vnet dot ibm dot com>
- Date: Thu, 20 Feb 2014 12:09:13 +0000
- Subject: Re: ARM inline assembly usage in Linux kernel
- Authentication-results: sourceware.org; auth=none
- References: <20140219025428 dot GA5417 at lithium dot compnerd dot org> <CA+=Sn1kr+Vjf8bRRvg7nTzdPw3YCgHPYff4vFBEyN3jJFcZRQw at mail dot gmail dot com> <87sirfjovh dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAMSE1kc3e=o1PxZj06ZUmxT+qbYrTz6oqELgDOGW8roOvWEZMQ at mail dot gmail dot com> <CA+=Sn1=hk63Fna77h1aWypaZt=p+u-4XzuO303=aWOZri=5Tsw at mail dot gmail dot com>
On 19/02/14 23:19, Andrew Pinski wrote:
> On Wed, Feb 19, 2014 at 3:17 PM, Renato Golin <renato.golin@linaro.org> wrote:
>> On 19 February 2014 11:58, Richard Sandiford
>> <rsandifo@linux.vnet.ibm.com> wrote:
>>> I agree that having an unrecognised asm shouldn't be a hard error until
>>> assembly time though. Saleem, is the problem that this is being rejected
>>> earlier?
>>
>> Hi Andrew, Richard,
>>
>> Thanks for your reviews! We agree that we should actually just ignore
>> the contents until object emission.
>>
>> Just for context, one of the reasons why we enabled inline assembly
>> checks is for some obscure cases when the snippet changes the
>> instructions set (arm -> thumb) and the rest of the function becomes
>> garbage. Our initial implementation was to always emit .arm/.thumb
>> after *any* inline assembly, which would become a nop in the worst
>> case. But since we had easy access to the assembler, we thought: "why
>> not?".
>
> With the unified assembly format, you should not need those
> .arm/.thumb and in fact emitting them can make things even worse.
>
Nonsense. If an inline assembly statement changed the state and didn't
put it back again, then all hell could break loose afterwards, including
getting bogus error messages out of the assembler that would appear to
the user as bugs in the compiler. Also not all instructions have duals
in the other instruction set (eg. ORN in thumb has no dual in ARM and
RSB has no dual in thumb).
Furthermore, GCC has to understand some things about inline assembly in
order to get literal pool placement (and in Thumb1 branch ranges)
correct. It has to assume that an inline assembly block generates no
more than 4 bytes of code per statement in the assembly (so .size
<some-large-number>) is certainly going to cause problems.
Inline assembly can't be an entirely opaque blob.
R.
> Thanks,
> Andrew Pinski
>
>
>>
>> The idea is now to try to parse the snippet for cases like .arm/.thumb
>> but only emit a warning IFF -Wbad-inline-asm (or whatever) is set (and
>> not to make it on by default), otherwise, ignore. We're hoping our
>> assembler will be able to cope with the multiple levels of indirection
>> automagically. ;)
>>
>> Thanks again!
>> --renato
>