breaking on open(2) on linux

breaking on open(2) on linux

[Marty Leisner]

I've used gdb for 20 years...I've found the ability to 
break on a system call and then backtrace very useful when
reverse engineering code

Now, I can't do it (not sure when I last could -- I recall its been
a problem before, but I worked around it).

strace shows open(2) calls...

I have no problem breaking on exit(3) or _exit(2) -- or write(2). 
But I can't seem to break on
open(2).

I'm using ubuntu 7.10 with recent gdb/gcc...

marty

Re: breaking on open(2) on linux

[Kip Macy]

On Sat, Apr 12, 2008 at 3:37 PM, Marty Leisner <leisner@rochester.rr.com> wrote:
> I've used gdb for 20 years...I've found the ability to
>  break on a system call and then backtrace very useful when
>  reverse engineering code
>
>  Now, I can't do it (not sure when I last could -- I recall its been
>  a problem before, but I worked around it).
>
>  strace shows open(2) calls...
>
>  I have no problem breaking on exit(3) or _exit(2) -- or write(2).
>  But I can't seem to break on
>  open(2).
>
>  I'm using ubuntu 7.10 with recent gdb/gcc...

It almost certainly just means that linux is doing a non-interruptible
sleep. There may be some part in the code that isn't equipped to
handle EINTR.  I can come up with a number of cases where this might
be the case. On a socket this would surprise me, but for example the
name lookup code in the file system may have cases where it is
intended to run to completion.

       -Kip

Re: breaking on open(2) on linux

[Nick Roberts]

Marty Leisner writes:
 > I've used gdb for 20 years...I've found the ability to 
 > break on a system call and then backtrace very useful when
 > reverse engineering code
 > 
 > Now, I can't do it (not sure when I last could -- I recall its been
 > a problem before, but I worked around it).
 > 
 > strace shows open(2) calls...

The breakpoint is probably being set elsewhere, e.g. open in libpthread.so

To find out do:

(gdb) inf addr open
Symbol "open" is at 0xb77e69c0 in a file compiled without debugging.

(gdb) inf sharedlibrary

...
0xb7800450  0xb784b444  Yes         /usr/lib/libglib-2.0.so.0
0xb77de250  0xb77e9264  Yes         /lib/tls/i686/cmov/libpthread.so.0
^^^^^^^^^^^^^^^^^^^^^^
0xb77d3150  0xb77d7bd4  Yes         /usr/lib/libSM.so.6
...

You probably want the one here:

0xb74abca0  0xb75a3306  Yes         /lib/tls/i686/cmov/libc.so.6


I don't know the official way to get round this but you could do

(gdb) set auto-solib-add off
(gdb) start
(gdb) share libc.so
(gdb) b open

to set the breakpoint where you want it.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: breaking on open(2) on linux

[Daniel Jacobowitz]

On Sun, Apr 13, 2008 at 11:12:05AM +1200, Nick Roberts wrote:
> Marty Leisner writes:
>  > I've used gdb for 20 years...I've found the ability to 
>  > break on a system call and then backtrace very useful when
>  > reverse engineering code
>  > 
>  > Now, I can't do it (not sure when I last could -- I recall its been
>  > a problem before, but I worked around it).
>  > 
>  > strace shows open(2) calls...
> 
> The breakpoint is probably being set elsewhere, e.g. open in libpthread.so

Nowadays (6.8) you'll get a breakpoint at every copy so it should work
OK.

Glibc is not good about passing all calls to e.g. open through the
"open" function.  Many will be inlined.  GDB does not support stopping
on system calls, though I hope it will some day (someone tried to
contribute this, but the assignment paperwork never went through and I
can no longer reach him).

-- 
Daniel Jacobowitz
CodeSourcery

Re: breaking on open(2) on linux

[Marty Leisner]

Well, I gave in -- I built it static.

Turns out open went through a symbol __open_nocancel.

For some reason, I can't break here with a shared library


marty

Re: breaking on open(2) on linux

[Marty Leisner]

Daniel Jacobowitz <drow@false.org> writes  on Sun, 13 Apr 2008 00:18:33 -0400
     > > Marty Leisner writes:
     > >  > I've used gdb for 20 years...I've found the ability to 
     > >  > break on a system call and then backtrace very useful when
     > >  > reverse engineering code
     > >  > 
     > >  > Now, I can't do it (not sure when I last could -- I recall its been
     > >  > a problem before, but I worked around it).
     > >  > 
     > >  > strace shows open(2) calls...
     > > 
     > 
     > Glibc is not good about passing all calls to e.g. open through the
     > "open" function.  Many will be inlined.  GDB does not support stopping
     > on system calls, though I hope it will some day (someone tried to
     > contribute this, but the assignment paperwork never went through and I
     > can no longer reach him).
     > 
     > -- 

I always felt it would be useful to embed some of the capability of strace into 
gdb...an "strace mode" where gdb gives strace like output until a breakpoint is
hit...

Stopping on system calls IMHO is a very useful feature....
I think I'm going to look into this...

I'm not sure why the static and the shared are acting very different (guess
its time to build glibc ;-().

marty

Re: breaking on open(2) on linux

[Nick Roberts]

 > > The breakpoint is probably being set elsewhere, e.g. open in libpthread.so
 > 
 > Nowadays (6.8) you'll get a breakpoint at every copy so it should work
 > OK.

Do you mean multiple breakpoint locations?  With 6.8.50.20080411-cvs I just get
one address: the one in libpthread.so.

My `solution' was wrong though, as the symbols for libpthread.so just get
read when a breakpoint is set on open.

For some reason in GDB 6.6, a pending breakpoint gets resolved in libc.so
while in 6.8.50.20080411-cvs it gets resolved in  libpthread.so.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: breaking on open(2) on linux

[Daniel Jacobowitz]

On Sun, Apr 13, 2008 at 08:55:55PM +1200, Nick Roberts wrote:
> Do you mean multiple breakpoint locations?  With 6.8.50.20080411-cvs I just get
> one address: the one in libpthread.so.

Indeed it does not seem to work:

#12 0x0000000000000000 in ?? ()
(gdb) i func ^open$
All functions matching regular expression "^open$":

Non-debugging symbols:
0x00002aaaaaabea70  open
0x00002aaaadc21a50  open
0x00002aaaadc21a50  open
(gdb) b open
Breakpoint 2 at 0x2aaaadc21a50
(gdb) i breakpoints
Num     Type           Disp Enb Address            What
1       breakpoint     del  y   <PENDING>          main
2       breakpoint     keep y   0x00002aaaadc21a50 <open>

Vladimir, can you see any reason this wouldn't work with multiple
minimal symbols?  Maybe the multiple location support is entirely
in the partial/full symbol and line number based breakpoint support?

-- 
Daniel Jacobowitz
CodeSourcery

Re: breaking on open(2) on linux

[Vladimir Prus]

On Monday 14 April 2008 01:38:03 Daniel Jacobowitz wrote:
> On Sun, Apr 13, 2008 at 08:55:55PM +1200, Nick Roberts wrote:
> > Do you mean multiple breakpoint locations?  With 6.8.50.20080411-cvs I just get
> > one address: the one in libpthread.so.
> 
> Indeed it does not seem to work:
> 
> #12 0x0000000000000000 in ?? ()
> (gdb) i func ^open$
> All functions matching regular expression "^open$":
> 
> Non-debugging symbols:
> 0x00002aaaaaabea70  open
> 0x00002aaaadc21a50  open
> 0x00002aaaadc21a50  open
> (gdb) b open
> Breakpoint 2 at 0x2aaaadc21a50
> (gdb) i breakpoints
> Num     Type           Disp Enb Address            What
> 1       breakpoint     del  y   <PENDING>          main
> 2       breakpoint     keep y   0x00002aaaadc21a50 <open>
> 
> Vladimir, can you see any reason this wouldn't work with multiple
> minimal symbols?  Maybe the multiple location support is entirely
> in the partial/full symbol and line number based breakpoint support?

The multiple location support only works if there line number information
for all locations.

We discussed this (maybe internally) -- the really right solution would
require modifying the symbol table interfacecs to allow to return several
symbols for a single name. It's hard.

- Volodya

Re: breaking on open(2) on linux

[Eli Zaretskii]

> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Tue, 15 Apr 2008 12:11:33 +0400
> 
> The multiple location support only works if there line number information
> for all locations.

This is important enough to mention in the manual.  Is it there? if it
is, I cannot find it.

Re: breaking on open(2) on linux

[Vladimir Prus]

On Wednesday 16 April 2008 00:34:30 Eli Zaretskii wrote:
> > From: Vladimir Prus <vladimir@codesourcery.com>
> > Date: Tue, 15 Apr 2008 12:11:33 +0400
> > 
> > The multiple location support only works if there line number information
> > for all locations.
> 
> This is important enough to mention in the manual.  Is it there? if it
> is, I cannot find it.

It's not there.

- Volodya

Re: breaking on open(2) on linux

[Eli Zaretskii]

> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Wed, 16 Apr 2008 12:09:30 +0400
> Cc: nickrob@snap.net.nz,  leisner@rochester.rr.com,  gdb@sourceware.org
> 
> On Wednesday 16 April 2008 00:34:30 Eli Zaretskii wrote:
> > > From: Vladimir Prus <vladimir@codesourcery.com>
> > > Date: Tue, 15 Apr 2008 12:11:33 +0400
> > > 
> > > The multiple location support only works if there line number information
> > > for all locations.
> > 
> > This is important enough to mention in the manual.  Is it there? if it
> > is, I cannot find it.
> 
> It's not there.

It is now (committed):

2008-04-20  Eli Zaretskii  <eliz@gnu.org>

	* gdb.texinfo (Set Breaks): Mention that multiple location
	breakpoints need line number info.  Add index entries.

Index: gdb/doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.482
diff -u -r1.482 gdb.texinfo
--- gdb/doc/gdb.texinfo	20 Apr 2008 00:03:25 -0000	1.482
+++ gdb/doc/gdb.texinfo	20 Apr 2008 09:04:38 -0000
@@ -3072,11 +3072,12 @@
 the breakpoints are conditional, this is even useful
 (@pxref{Conditions, ,Break Conditions}).
 
+@cindex multiple locations, breakpoints
+@cindex breakpoints, multiple locations
 It is possible that a breakpoint corresponds to several locations
 in your program.  Examples of this situation are:
 
 @itemize @bullet
-
 @item
 For a C@t{++} constructor, the @value{NGCC} compiler generates several
 instances of the function body, used in different cases.
@@ -3088,11 +3089,14 @@
 @item
 For an inlined function, a given source line can correspond to
 several places where that function is inlined.
-
 @end itemize
 
 In all those cases, @value{GDBN} will insert a breakpoint at all
-the relevant locations.
+the relevant locations@footnote{
+As of this writing, multiple-location breakpoints work only if there's
+line number information for all the locations.  This means that they
+will generally not work in system libraries, unless you have debug
+info with line numbers for them.}.
 
 A breakpoint with multiple locations is displayed in the breakpoint
 table using several rows---one header row, followed by one row for

Re: breaking on open(2) on linux

[Vladimir Prus]

On Sunday 20 April 2008 13:08:52 Eli Zaretskii wrote:
> > From: Vladimir Prus <vladimir@codesourcery.com>
> > Date: Wed, 16 Apr 2008 12:09:30 +0400
> > Cc: nickrob@snap.net.nz,  leisner@rochester.rr.com,  gdb@sourceware.org
> > 
> > On Wednesday 16 April 2008 00:34:30 Eli Zaretskii wrote:
> > > > From: Vladimir Prus <vladimir@codesourcery.com>
> > > > Date: Tue, 15 Apr 2008 12:11:33 +0400
> > > > 
> > > > The multiple location support only works if there line number information
> > > > for all locations.
> > > 
> > > This is important enough to mention in the manual.  Is it there? if it
> > > is, I cannot find it.
> > 
> > It's not there.
> 
> It is now (committed):
> 
> 2008-04-20  Eli Zaretskii  <eliz@gnu.org>
> 
> 	* gdb.texinfo (Set Breaks): Mention that multiple location
> 	breakpoints need line number info.  Add index entries.

Thanks!

- Volodya