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