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] S/390: Improve storing asan frame_pc



> Am 02.07.2019 um 15:39 schrieb Jakub Jelinek <jakub@redhat.com>:
> 
> On Tue, Jul 02, 2019 at 03:33:28PM +0200, Ilya Leoshkevich wrote:
>>> Am 02.07.2019 um 15:19 schrieb Segher Boessenkool <segher@kernel.crashing.org>:
>>> 
>>> On Tue, Jul 02, 2019 at 08:02:16AM -0500, Segher Boessenkool wrote:
>>>> On Tue, Jul 02, 2019 at 10:51:54AM +0200, Ilya Leoshkevich wrote:
>>>>> +#undef TARGET_INSN_ALIGNMENT
>>>>> +#define TARGET_INSN_ALIGNMENT 16
>>>> 
>>>> There already is FUNCTION_BOUNDARY for something similar, which fits in
>>>> well with STACK_BOUNDARY, PARM_BOUNDARY, many more *_BOUNDARY.  I realise
>>>> you may prefer a hook, but as long as we aren't getting rid of all the
>>>> other macros, what's the point?
>>> 
>>> And maybe LABEL_BOUNDARY is bettter for this than INSN_BOUNDARY as well?
>> 
>> Can’t we just use FUNCTION_BOUNDARY then?
>> I think .LASANPC is always emitted at the beginning of a function.
> 
> Isn't e.g. the hotpatch sequence emitted before it?

You are right, with -fpatchable-function-entry it’s moved.

So, I guess I should stick with the current approach.
I could change TARGET_INSN_ALIGNMENT hook to INSN_BOUNDARY macro if that
would better match the current design.  I would still call it INSN, and
not LABEL, because LABEL can refer to data.


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