This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Frame pointer for arm with THUMB2 mode


On 05/09/18 17:43, Denis Khalikov wrote:
> Thanks for the answers.
> 
> I understood that, this hack makes more mess in codegen for arm,
> but can you please clarify what did you mean by
> 
>>Only a single register can be used
>> as the frame chain.
> 
> As far as I understood, GCC for arm with THUMB2 mode uses r7 register as
> frame pointer register by default (with -fno-omit-frame-pointer flag),
> GCC for arm with ARM mode uses r11, so I didn't really propose
> to change the frame pointer register.
> 

On entry to a function the code has to save the existing frame register.
 It doesn't know (can't trivially know) whether the caller is code
compiled in Arm state or Thumb state.  So how can it save the caller's
frame register if they are not the same?

Furthermore, the 'other' frame register (ie r7 in Arm state, r11 in
Thumb) is available as a call-saved register, so can contain any random
value.  If you try to use that random value during a frame chain walk
your program will most like take an access violation.  It will certainly
give you a garbage frame chain.

R.

> Thanks.
> 
> On 09/05/2018 06:32 PM, Wilco Dijkstra wrote:
>> Hi Denis,
>>
>>>> Adding support for a frame chain would require an ABI change. It
>>> would have to
>>>  > work across GCC, LLVM, Arm, Thumb-1 and Thumb-2 - not a trivial
>>> amount of
>>>  > effort.
>>
>>> Clang already works that way.
>>
>> No, that's incorrect like Richard pointed out. Only a single register
>> can be used
>> as the frame chain.
>>
>>> If we change the size of the traces to 2, it could be something like
>>> this:
>> ...
>>> At the first example we lost the full context, from where the
>>> control/data flow comes from.
>>
>> If 2 is not sufficient, then try 3 or 4. It may also be feasible to
>> only enable
>> deeper unwinding for particular libraries so you only pay an extra
>> cost for
>> leaks you are interested in.
>>
>>> The stack layout like this enables only with compile time flag
>>> (-mthumb-fp and works only together with -mthumb and
>>> -fno-omit-frame-pointer). It does not affect other codegen.
>>
>> But any code built like that will *always* run slower even if you
>> don't use
>> the sanitizer.
>>
>> Wilco
>>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]