This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix a crash when displaying variables from shared library.
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, Joel Brobecker <brobecker at adacore dot com>, tromey at redhat dot com
- Date: Wed, 18 Mar 2009 02:49:10 +0000
- Subject: Re: [patch] Fix a crash when displaying variables from shared library.
- References: <20090205030257.8A6073A6B7A@localhost> <20090305200415.GC3744@adacore.com> <8ac60eac0903051546r1eaffc89tf1f35b21e6dc1b40@mail.gmail.com>
Hi guys,
On Thursday 05 March 2009 23:46:32, Paul Pluzhnikov wrote:
> > I suggest a different approach:
> >
> > ?| # Start the program, we should land in the program main procedure
> > ?| if { [gdb_start_cmd] < 0 } {
> > ?| ? ? fail "Can't run to main"
> > ?| ? ? return -1
> > ?| }
> > ?|
> > ?| gdb_test "" \
> > ?| ? ? ? ? ?"first \\(\\) at .*first.adb.*" \
> > ?| ? ? ? ? ?"start first"
> >
> > The second gdb_test should allow you to verify that the debugger
> > displays your variables correctly.
>
> Looks good.
>
> Attached is the patch I just committed.
I just noticed that this test is failing against gdbserver:
FAIL: gdb.base/solib-display.exp: Can't run to main (2)
The problem is that gdb_start_cmd is a nop for remote targets:
proc gdb_start_cmd {args} {
...
if [target_info exists use_gdb_stub] {
return -1
}
What do you think? Should we skip this test for remote
targets, or perhaps we do things differently here?
--
Pedro Alves