Re: [PATCH] S/390: Improve storing asan frame_pc

[Segher Boessenkool <segher@kernel.crashing.org>]

On Tue, Jul 02, 2019 at 03:55:56PM +0200, Ilya Leoshkevich wrote:
> > 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.

On some archs LABEL_BOUNDARY can be bigger than INSN_BOUNDARY (just like
FUNCTION_BOUNDARY can be even bigger, like on 390 :-) )

Either will work for your purposes afaics.

LABEL in RTL is always a CODE_LABEL I think?  Maybe CODE_LABEL_BOUNDARY
would make it clearer, it's not like a short name for this is useful
anyway.


Segher