Re: [RFC] canonical linespec and multiple breakpoints ...

Re: [RFC] canonical linespec and multiple breakpoints ...

[Avi Gozlan]

Hello,

On the basis of your proposal dealing with supporting multiple breakpoints and the discussion that followed it, I would like to raise some questions. These issues are highly relevant for our needs (the need was first described in bug 12313 in the GDB bug database).

Among varying GDB uses, we use GDB to debug a process which loads (using dlopen) the same exact library multiple times (in fact there are copies of the library otherwise dlopen returns the same handle for each load). We find your proposal very useful for us to be able to attach to the process and debug a specific library. Though, we do have some questions and suggestions. Pardon technical inaccuracies in GDB terminology.
 
1) The proposal discusses function breakpoints. Will it also enable inspecting global and static variables from a specific library?

2) Just to make sure we understand the interaction of the user interface with "set multiple-symbols": it will be possible to request GDB for a specific variable/function by a library name without getting it from all libraries or get a question (ask) each time, right? Otherwise it will be very inconvenient to inspect multiple variables within a given library.

3) Will the library specific interface know how to handle non-stripped libraries that are compiled without debug information (no "-g")?

4) We suggest adding an option to enable the GDB backtrace command to show the library name for each function. In our usage case we have scenarios in which the libraries interact with each other and a backtrace showing the library name for each function can enable us understand the interaction perfectly.

5) Perhaps a little pedantic but what about handling symbols with different names in libraries with identical name which lie in different paths?

Thanks,

Avi

RE: Re: [RFC] canonical linespec and multiple breakpoints ...

[Avi Gozlan]

Any reference to the below issues would be appreciated. Thanks.

-----Original Message-----
From: Avi Gozlan 
Sent: Sunday, September 18, 2011 1:22 PM
To: 'Tom Tromey'; 'gdb-patches@sourceware.org'
Cc: Avi Gozlan; Matan Ben Gur
Subject: Re: [RFC] canonical linespec and multiple breakpoints ...

Hello,

On the basis of your proposal dealing with supporting multiple breakpoints
and the discussion that followed it, I would like to raise some questions. 
These issues are highly relevant for our needs (the need was first described
in bug 12313 in the GDB bug database).

Among varying GDB uses, we use GDB to debug a process which loads (using 
dlopen) the same exact library multiple times (in fact there are copies of
the library otherwise dlopen returns the same handle for each load). We find
your proposal very useful for us to be able to attach to the process and 
debug a specific library. Though, we do have some questions and suggestions.
Pardon technical inaccuracies in GDB terminology.

1) The proposal discusses function breakpoints. Will it also enable 
inspecting global and static variables from a specific library?

2) Just to make sure we understand the interaction of the user interface 
with "set multiple-symbols": it will be possible to request GDB for a 
specific variable/function by a library name without getting it from all
libraries or get a question (ask) each time, right? Otherwise it will be
very inconvenient to inspect multiple variables within a given library.

3) Will the library specific interface know how to handle non-stripped 
libraries that are compiled without debug information (no "-g")?

4) We suggest adding an option to enable the GDB backtrace command to 
show the library name for each function. In our usage case we have 
scenarios in which the libraries interact with each other and a backtrace 
showing the library name for each function can enable us understand the 
interaction perfectly.

5) Perhaps a little pedantic but what about handling symbols with 
different names in libraries with identical name which lie in different 
paths?

Thanks,

Avi

Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey]

>>>>> "Avi" == Avi Gozlan <avi@checkpoint.com> writes:

Sorry about the delay in my reply.  I was offline all of September.

Avi> Among varying GDB uses, we use GDB to debug a process which loads
Avi> (using dlopen) the same exact library multiple times (in fact there
Avi> are copies of the library otherwise dlopen returns the same handle for
Avi> each load).

Avi> 1) The proposal discusses function breakpoints. Will it also enable
Avi> inspecting global and static variables from a specific library?

No, I'm afraid not.

I think implementing something for variables could be done, but it would
be a separate project, maybe with a different approach.  I can advise if
you are interested in this.

Avi> 2) Just to make sure we understand the interaction of the user
Avi> interface with "set multiple-symbols": it will be possible to request
Avi> GDB for a specific variable/function by a library name without getting
Avi> it from all libraries or get a question (ask) each time, right?
Avi> Otherwise it will be very inconvenient to inspect multiple variables
Avi> within a given library.

Yes, this will work as you expect.

Avi> 3) Will the library specific interface know how to handle non-stripped
Avi> libraries that are compiled without debug information (no "-g")?

Yes.  This is already implemented on my branch.  It improves GDB's
behavior here, so that the right thing happens if you have multiple
instance of a name where some symbols have debuginfo and some do not.

Avi> 4) We suggest adding an option to enable the GDB backtrace command to
Avi> show the library name for each function. In our usage case we have
Avi> scenarios in which the libraries interact with each other and a
Avi> backtrace showing the library name for each function can enable us
Avi> understand the interaction perfectly.

There was an earlier thread about this, I'm not sure what happened in
the end though.  I think this would be a good addition.  If there is no
bug report for this, could you file one?

Avi> 5) Perhaps a little pedantic but what about handling symbols with
Avi> different names in libraries with identical name which lie in
Avi> different paths?

I didn't implement the "objfile" prefix stuff yet, but my plan is to let
you specify as much of the path as you want, e.g.:

  break libsomething.so:function
  break /lib/libsomething.so:function
  break some/leading/dirs/libsomething.so:function

Tom