This is the mail archive of the gcc@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]

[middle-end] How to handle fake register in DECL_INCOMING_RTL?


When implementing interrupt attribute for x86 interrupt handlers, we
have a difficult time to access interrupt data passed down by x86
processors.  On x86, interrupt handlers are only called by processors
which push interrupt data onto stack at the address where the normal
return address is.  Interrupt handlers must access interrupt data via
pointers so that they can update interrupt data.

TARGET_FUNCTION_ARG_ADVANCE is skipped by interrupt handlers since they
are only called by processors.  Since interrupt data is at one word
below the normal argument location on stack and must be accessed via
pointer, we changed TARGET_FUNCTION_ARG to return a fake hard register
for interrupt handlers and updated expander to covert the fake register
to its address on stack.

However, we run into problems with

/* For PARM_DECL, holds an RTL for the stack slot or register
   where the data was actually passed.  */
#define DECL_INCOMING_RTL(NODE) \
   (PARM_DECL_CHECK (NODE)->parm_decl.incoming_rtl)

>From what I can tell, DECL_INCOMING_RTL is a constant after it is set up.
For interrupt handlers, DECL_INCOMING_RTL contains a fake register,
which isn't a problem in codegen since it is covered by expander.  But
DECL_INCOMING_RTL is also used to generate debug information and debug
output never expects a fake register in DECL_INCOMING_RTL.  To work around
it, we changed x86 prologue expander to update DECL_INCOMING_RTL with the
fake register in interrupt handlers to its address on stack.

We are asking middle-end maintainers, is this a correct solution?  If not,
what other approaches should we try?


-- 
H.J.


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