This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB 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: [RFA] Fix small problems in rs6000-tdep.c:skip_prologue()


Kevin Buettner <kevinb@redhat.com> writes:
> > In this case, the stX 0,N(31) is spilling an argument, even though r0
> > is not an argument register.  ('evstdd' is an E500 instruction that
> > is definitely an argument spill.)
> 
> Do you have any idea why the compiler chose to arrange the code this way?
> Why couldn't it have just done "stb 3, 8(31)" and ommitted the "mr 0, 3"
> altogether?

I have no idea.  My attitude has always been that we just have to put
up with whatever junk we get.  GDB, by its nature, just has to cope
with whatever hair the upstream implementors come up with.

> > Clearly, both your function and mine need to go into the test suite...
> > 
> > What if we did something like this?  It'd need to be combined with the 
> > rest of your change, I'm just sketching:
> > 
> > *** rs6000-tdep.c.~1.191.~	2004-03-29 16:45:15.000000000 -0500
> > --- rs6000-tdep.c	2004-04-02 16:11:26.000000000 -0500
> > ***************
> > *** 441,446 ****
> > --- 441,447 ----
> >     int minimal_toc_loaded = 0;
> >     int prev_insn_was_prologue_insn = 1;
> >     int num_skip_non_prologue_insns = 0;
> > +   int r0_contains_argument = 0;
> >     const struct bfd_arch_info *arch_info = gdbarch_bfd_arch_info (current_gdbarch);
> >     struct gdbarch_tdep *tdep = gdbarch_tdep (current_gdbarch);
> >     
> > ***************
> > *** 509,519 ****
> > --- 510,524 ----
> >   	     ones.  */
> >   	  if (lr_reg < 0)
> >   	    lr_reg = (op & 0x03e00000);
> > +           if (lr_reg == 0)
> > +             r0_contains_argument = 0;
> 
> This special casing of r0 bothers me.  In your example above, what's to
> prevent the compiler from using some other scratch register, e.g. r11 or
> r12?  If it starts doing so, do we add more state variables to record this
> fact?

I guess so.

For what it's worth --- the analysis used in s390-tdep.c makes all
these problems just go away; it is able to recognize argument spills,
register saves, etc. done in almost any reasonable fashion.  Internal
to Red Hat, I've gotten the architecture-independent portions split
out; the arch-dependent code that's left over is pretty much just an
interpreter for prologue instructions.  In spare moments I've been
trying to put together enough platforms for PPC testing (Altivec!
E500!  AIX!  Embedded ABI!  Rah rah rah.) that this could be
approached with some sort of confidence.


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