how to access show/set data

how to access show/set data

[Kris Warkentin]

Say, for example, I wanted to programmatically modify solib_search_path, a
static char * which is declared in solib.c.

I know a pointer to it has been stored via the add_set_cmd function and I'm
wondering if there is a "approved" way for me to dig out this pointer.  I
have an OS dependent init file that needs to monkey with solib_search_path
and I didn't want to make the mods to solib.c or to make a "qnx_solib.c" for
such a small thing.

cheers,

Kris

Re: how to access show/set data

[Kris Warkentin]

Nevermind.  I found lookup_cmd().

cheers,

Kris

----- Original Message -----
From: "Kris Warkentin" <kewarken@qnx.com>
To: <gdb@sources.redhat.com>
Sent: Thursday, January 02, 2003 2:44 PM
Subject: how to access show/set data


> Say, for example, I wanted to programmatically modify solib_search_path, a
> static char * which is declared in solib.c.
>
> I know a pointer to it has been stored via the add_set_cmd function and
I'm
> wondering if there is a "approved" way for me to dig out this pointer.  I
> have an OS dependent init file that needs to monkey with solib_search_path
> and I didn't want to make the mods to solib.c or to make a "qnx_solib.c"
for
> such a small thing.
>
> cheers,
>
> Kris
>
>

GDB 5.2/5.3 breakpoint bug

[Sunil Alankar]

Hi,

 Attempting to set a class member function breakpoint (say break
myClass::funcOne) fails to set a proper break point in solaris 2.7.
This happens with GDB 5.2 and 5.3. Bug does not occur in GDB 5.1. Anybody
has any idea where to look?. I would appreciate any help.

Thx

Sunil

Re: GDB 5.2/5.3 breakpoint bug

[Daniel Jacobowitz]

On Fri, Jan 03, 2003 at 06:15:26PM -0800, Sunil Alankar wrote:
> Hi,
> 
>  Attempting to set a class member function breakpoint (say break
> myClass::funcOne) fails to set a proper break point in solaris 2.7.
> This happens with GDB 5.2 and 5.3. Bug does not occur in GDB 5.1. Anybody
> has any idea where to look?. I would appreciate any help.

What _does_ happen if it isn't a proper breakpoint?  Can you provide a
transcript?

What version of what compiler are you using?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: how to access show/set data

[Kevin Buettner]

On Jan 2,  2:44pm, Kris Warkentin wrote:

> Say, for example, I wanted to programmatically modify solib_search_path, a
> static char * which is declared in solib.c.
> 
> I know a pointer to it has been stored via the add_set_cmd function and I'm
> wondering if there is a "approved" way for me to dig out this pointer.  I
> have an OS dependent init file that needs to monkey with solib_search_path
> and I didn't want to make the mods to solib.c or to make a "qnx_solib.c" for
> such a small thing.

Why not just put set solib-search-path in your .gdbinit file?

(I don't know of any "approved" way of digging out the pointer.)

Kevin

Re: how to access show/set data

[Kris Warkentin]

Actually, I had replied to my own post (you must have missed it) but the
lookup_cmd() function in cli-decode.c does the trick nicely.  The reason we
don't use .gdbinit is because we ship our tools in an odd set of places
(depending on which host) and it's easier to have defaults than to force
customers to use a .gdbinit.  Besides, where do you put your gdbinit on a
windows host? ;-)

cheers,

Kris

----- Original Message -----
From: "Kevin Buettner" <kevinb@redhat.com>
To: "Kris Warkentin" <kewarken@qnx.com>; <gdb@sources.redhat.com>
Sent: Wednesday, January 08, 2003 6:15 PM
Subject: Re: how to access show/set data


> On Jan 2,  2:44pm, Kris Warkentin wrote:
>
> > Say, for example, I wanted to programmatically modify solib_search_path,
a
> > static char * which is declared in solib.c.
> >
> > I know a pointer to it has been stored via the add_set_cmd function and
I'm
> > wondering if there is a "approved" way for me to dig out this pointer.
I
> > have an OS dependent init file that needs to monkey with
solib_search_path
> > and I didn't want to make the mods to solib.c or to make a "qnx_solib.c"
for
> > such a small thing.
>
> Why not just put set solib-search-path in your .gdbinit file?
>
> (I don't know of any "approved" way of digging out the pointer.)
>
> Kevin
>

Re: how to access show/set data

[Christopher Faylor]

On Thu, Jan 09, 2003 at 08:32:15AM -0500, Kris Warkentin wrote:
>Besides, where do you put your gdbinit on a windows host?  ;-)

In your home directory, same as UNIX.

cgf

Re: how to access show/set data

[Kris Warkentin]

Not quite that simple.  If I have to provide a .gdbinit file for EVERY user
in order for gdb to properly find our libs, how do I write an installer that
does the right thing?  Some users might use Cygwin, some might not.  $HOME
might be set, it might not.  If I'm installing to Solaris or Linux, which
user accounts do I install a .gdbinit in?  It's non-trivial, especially when
you ship tools where various cpu targets have their libs in
$QNX_TARGET/$CPU/lib, and so on.  We ship gdb targetting 5 different CPU's
(arm, mips, powerpc, sh, i386) on 4 different hosts (QNX, Solaris, Linux and
Windows) so having a routine that programmatically sets up some defaults for
where host and target files are is the only sensible way to go.

Either way, I found a nice clean way to do it so I'm happy.  By the way, one
my coworkers wrote a very small enhancement to the .gdbinit code that I
would like to submit.  Basically it allows a backend writer to define
EXTRA_GDBINIT_FILENAME to a string which will be pre-pended to .gdbinit for
initial sourcing.  ie. We define it to be .ntoCPU-gdbinit and then if, for
instance, our x86 targetting gdb finds $HOME/.ntox86-gdbinit, it reads it
instead.  This is really handy for us because most of our development is
targetting remote machines so this way you can automatically connect to the
cpu target when you start gdb.  All you need then is 'source .gdbinit' at
the end of your cpu specific one and you can have specific and generic
sections for your init code.

Sorry about the patch (I just diffed it from CVS so you could take a look).
If you're interested in accepting this, I'll patch your CVS head branch and
submit a diff against that.

cheers,

Kris

Index: main.c
===================================================================
RCS file: /product/tools/gdb/gdb/main.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -c -r1.2 -r1.3
*** main.c 6 Sep 2002 20:20:43 -0000 1.2
--- main.c 6 Sep 2002 21:23:46 -0000 1.3
***************
*** 524,534 ****
    homedir = getenv ("HOME");
    if (homedir)
      {
!       homeinit = (char *) alloca (strlen (homedir) +
!       strlen (gdbinit) + 10);
!       strcpy (homeinit, homedir);
!       strcat (homeinit, "/");
!       strcat (homeinit, gdbinit);

        if (!inhibit_gdbinit)
   {
--- 524,553 ----
    homedir = getenv ("HOME");
    if (homedir)
      {
!       /* Allow for a target specific gdbinit that will only override
!       the default gdbinit if it exists.  GP QNX Sep 6 2002 */
!       homeinit = 0;
!       if (extragdbinit)
!         {
!           homeinit = (char *) alloca (strlen (homedir) +
!                                       strlen (extragdbinit) + 10);
!
!           strcpy (homeinit, homedir);
!           strcat (homeinit, "/");
!           strcat (homeinit, extragdbinit);
!
!           if (stat (homeinit, &homebuf) < 0)
!               homeinit = 0;
!         }
!
!       if (!homeinit)
!         {
!           homeinit = (char *) alloca (strlen (homedir) +
!         strlen (gdbinit) + 10);
!           strcpy (homeinit, homedir);
!           strcat (homeinit, "/");
!           strcat (homeinit, gdbinit);
!         }

        if (!inhibit_gdbinit)
   {
Index: top.h
===================================================================
RCS file: /product/tools/gdb/gdb/top.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -c -r1.2 -r1.3
*** top.h 6 Sep 2002 20:20:47 -0000 1.2
--- top.h 6 Sep 2002 21:23:46 -0000 1.3
***************
*** 30,35 ****
--- 30,36 ----
  extern int inhibit_gdbinit;
  extern int epoch_interface;
  extern char gdbinit[];
+ extern char *extragdbinit;

  extern void print_gdb_version (struct ui_file *);

Index: top.c
===================================================================
RCS file: /product/tools/gdb/gdb/top.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -c -r1.2 -r1.3
*** top.c 6 Sep 2002 20:20:47 -0000 1.2
--- top.c 6 Sep 2002 21:23:46 -0000 1.3
***************
*** 76,81 ****
--- 76,87 ----
  #endif
  char gdbinit[] = GDBINIT_FILENAME;

+ #ifndef EXTRA_GDBINIT_FILENAME
+ #define EXTRA_GDBINIT_FILENAME 0
+ #endif
+
+ char *extragdbinit = EXTRA_GDBINIT_FILENAME;
+
  int inhibit_gdbinit = 0;

  /* If nonzero, and GDB has been configured to be able to use windows,

----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
To: <gdb@sources.redhat.com>
Sent: Thursday, January 09, 2003 1:21 PM
Subject: Re: how to access show/set data


> On Thu, Jan 09, 2003 at 08:32:15AM -0500, Kris Warkentin wrote:
> >Besides, where do you put your gdbinit on a windows host?  ;-)
>
> In your home directory, same as UNIX.
>
> cgf
>

Re: how to access show/set data

[Kris Warkentin]

> would like to submit.  Basically it allows a backend writer to define
> EXTRA_GDBINIT_FILENAME to a string which will be pre-pended to .gdbinit
for
> initial sourcing.  ie. We define it to be .ntoCPU-gdbinit and then if, for

Oops...not prepended.  Just defined.  Sorry.

Kris