[RFA] Fix small problems in rs6000-tdep.c:skip_prologue()

[Jim Blandy]

Jim Blandy <jimb@redhat.com> writes:

> Joel Brobecker <brobecker@gnat.com> writes:
> 
> > > I'd prefer that you add them to gdb.asm, unless it's likely to produce
> > > strange prologues on other architectures.
> > 
> > I looked at the gdb.asm subdirectory, and found only one test there:
> > asm-source.exp. It doesn't look like this testcase would be the correct
> > location where to add a test for this prologue.
> > 
> > So should I add a new testcase? This testcase would only be activated
> > for powerpc*-*-* targets.
> > 
> > In terms of the code, I would just dump the assembly code for the
> > function in question into an .s file. To perform the link, I'm tempted
> > between do it all in asm (just as we do in asm-source.exp), or see
> > if it is simpler if I use a C main...
> > 
> > All the testcase would do is: Build the executable, load it, and then
> > insert a breakpoint in my function.
> > 
> > Am I on the right track?
> 
> Well, that's what I had in mind.  One file for each architecture,
> packed full of functions with interesting prologues.  The tests would
> just set breakpoints on each of them and check that they get set at
> the right distance from the entry point.
> 
> My test case uses E500-specific instructions.  I could rewrite it so
> it didn't, but the prologue analyzer does have E500-specific code, so
> it needs to be tested anyway.  So I'd probably need a separate test
> file.

Okay, I see now that i386-prologue.c actually contains top-level 'asm'
statements that explicitly spell out the instruction sequence to test.
I had jumped to the conclusion that these were just C functions for
which some compiler at some point in the past had generated prologues
that confused GDB.  Doing things the way i386-prologue.c does makes
sense to me.