Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp

[will schmidt via Gdb-patches <gdb-patches@sourceware.org>]

On Mon, 2022-08-15 at 19:31 +0000, Thiago Jung Bauermann wrote:
> Hello,
> 
> will schmidt via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> > On Mon, 2022-08-15 at 09:54 -0700, Carl Love wrote:
> > > Tom:
> > > 
> > > OK, I took a look at how the test used to work and how it is now
> > > working and I see what the issue is. 
> > > 
> > > PowerPC has two entry points, local and global.  The test used to
> > > set
> > > the breakpoint for the function at the local entry point.  With
> > > your
> > > changes, the breakpoint is now being set at the global breakpoint
> > > which
> > > is before the local breakpoint.  The function is actually entered
> > > at
> > > the local breakpoint thus gdb never "sees" the breakpoint that
> > > was
> > > set.
> 
> [ <snip> ]
> 
> > > It looks to me that we need to make sure we set the breakpoint at
> > > the
> > > local address.  
> > > 
> > > Off hand, I am not sure how to get your changes to "proc
> > > gdb_continue_to_breakpoint" to select the local entry point not
> > > the
> > > global entry point.  Perhaps Ulrich has some ideas???
> > 
> > From a glance that the patch that updated dw2-dir-file-name.exp;
> > ( commit cd919f5533cc8aa495acd75a6f059e5fcf2e6af9 )
> > the change there was effectively
> > 
> > -       gdb_breakpoint $func
> > +       gdb_breakpoint *$func
> > 
> > with assorted regexp changes to match.
> > 
> > The patch description goes into detail, but I interpret the gist of
> > it
> > as avoiding the aarch64 architecture prologue skipper, since that
> > prologue skipper does something wrong, with entanglements in the
> > line
> > table info.
> > 
> > The powerpc prologue skipper (wherever it is) was presumably
> > handling
> > the local/global entry points properly.  Since the test now species
> > a
> > specific address (*$func), the prologue skipper is no longer
> > involved.
> > 
> > The patch should probably be reverted, but I defer to others if
> > I've
> > misunderstood part of this issue.. 
> 
> Is it possible to force the compiler to use the global entry point?

No.  :-)

> Perhaps by calling the function via a function pointer rather than as
> a
> regular function call? That would allow preserving the change to the
> testcase and making it work on ppc64le.
>