* RE: gdb 5.3 bug
@ 2003-03-05 16:54 Lev Assinovsky
0 siblings, 0 replies; 19+ messages in thread
From: Lev Assinovsky @ 2003-03-05 16:54 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
Is't is OK that configure didn't compile solib-sunos.c?
I caught _DEBUG symbol there which /usr/lib/ld.so.1 also has.
----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909
> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Wednesday, March 05, 2003 7:12 PM
> To: Lev Assinovsky
> Cc: gdb@sources.redhat.com
> Subject: Re: gdb 5.3 bug
>
>
> On Wed, Mar 05, 2003 at 07:07:41PM +0300, Lev Assinovsky wrote:
> > Yes, it does:
> > ----------
> > (gdb) set stop-on-solib-events 1
> > (gdb) r
> > Starting program:
> /export/home/lev/src/Installation/packages/Personal/LevAssinov
> sky/virtfun/load
> > warning: Unable to find dynamic linker breakpoint function.
> > GDB will be unable to debug shared library initializers
> > and track explicitly loaded dynamic code.
> > Stopped due to shared library event
> > -----------
> > But what the warning mean?
>
> That's the problem. You'll have to figure out why the symbol it's
> looking for is missing from your dynamic linker. It's looking for one
> of these:
> "r_debug_state",
> "_r_debug_state",
> "_dl_debug_state",
> "rtld_db_dlactivity",
> "_rtld_debug_state",
>
>
> >
> > Sincerely,
> > ----
> > Lev Assinovsky
> > Aelita Software Corporation
> > O&S Core Division, Programmer
> > ICQ# 165072909
> >
> >
> > > -----Original Message-----
> > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > Sent: Wednesday, March 05, 2003 6:57 PM
> > > To: Lev Assinovsky
> > > Cc: gdb@sources.redhat.com
> > > Subject: Re: gdb 5.3 bug
> > >
> > >
> > > I don't know. Does "set stop-on-solib-events 1" cause
> your program to
> > > stop?
> > >
> > > On Wed, Mar 05, 2003 at 05:27:09PM +0300, Lev Assinovsky wrote:
> > > > Daniel!
> > > > I was wrong!
> > > > I can step into the function of dynamic library if
> > > > I run the command "sharedlibrary" before.
> > > > Why are symbols coming in only after that command
> > > > and auto-solib-add (=on) doesn't work?
> > > >
> > > > ----
> > > > Lev Assinovsky
> > > > Aelita Software Corporation
> > > > O&S Core Division, Programmer
> > > > ICQ# 165072909
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > > Sent: Saturday, March 01, 2003 7:05 PM
> > > > > To: Lev Assinovsky
> > > > > Cc: gdb@sources.redhat.com
> > > > > Subject: Re: gdb 5.3 bug
> > > > >
> > > > >
> > > > > On Sat, Mar 01, 2003 at 06:59:45PM +0300, Lev
> Assinovsky wrote:
> > > > > > Dear Daniel!
> > > > > > Thank you very match for your advise!
> > > > > > Snapshot gdb+dejagnu-20030228 works just fine!
> > > > > > Thank a lot all guys who is involved in gdb development.
> > > > > > I am sorry but I have to bother you with another
> gdb problem.
> > > > > > The problem is I can't step into the function through
> > > the pointer
> > > > > > if the function resides in dynamically loaded shared object
> > > > > (library).
> > > > > > Here is the simple test case:
> > > > >
> > > > > Hmm. Your testcase works on GNU/Linux, so it must be
> related to
> > > > > i386-solaris shared library support. Maybe someone else
> > > on the list
> > > > > can help.
> > > > >
> > > > > >
> > > > > > 1. Shared object:
> > > > > > ---------- cut here --------
> > > > > > #include <iostream>
> > > > > > using namespace std;
> > > > > >
> > > > > > extern "C" {
> > > > > > void my_func()
> > > > > > {
> > > > > > cout << "This is my_func" << endl;
> > > > > > }
> > > > > >
> > > > > > }
> > > > > > ---------- cut here --------
> > > > > > 2. Main:
> > > > > > #include <iostream>
> > > > > > #include <memory>
> > > > > > #include <dlfcn.h>
> > > > > > #include <link.h>
> > > > > >
> > > > > > using namespace std;
> > > > > >
> > > > > > void * handle;
> > > > > >
> > > > > > typedef void ( *Func_t)();
> > > > > >
> > > > > > Func_t getFunc()
> > > > > > {
> > > > > > Func_t p = (Func_t)dlsym ( handle, "my_func" );
> > > > > > if ( NULL == p )
> > > > > > {
> > > > > > cout << dlerror() << endl;
> > > > > > exit(2);
> > > > > > }
> > > > > > return p;
> > > > > > }
> > > > > >
> > > > > > int main()
> > > > > > {
> > > > > > handle = (void*)
> > > > > ::dlopen("./func_so/bin/i386-sun-solaris/func_so.so",
> > > > > RTLD_NOW | RTLD_LOCAL | RTLD_GROUP);
> > > > > > if (handle == NULL)
> > > > > > {
> > > > > > cout << dlerror() << endl;
> > > > > > exit(2);
> > > > > > }
> > > > > >
> > > > > > Func_t f = getFunc();
> > > > > > f();
> > > > > > }
> > > > > > ---------- cut here --------
> > > > > >
> > > > > > This testcase works, but I can't step into f() (last
> > > line) in gdb.
> > > > > > Is it possible to work around or fix this problem?
> > > > > > Thanks in advance!
> > > > > >
> > > > > > ----
> > > > > > Lev Assinovsky
> > > > > > Aelita Software Corporation
> > > > > > O&S Core Division, Programmer
> > > > > > ICQ# 165072909
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > > > > Sent: Friday, February 28, 2003 8:19 PM
> > > > > > > To: Lev Assinovsky; gdb@sources.redhat.com
> > > > > > > Subject: Re: gdb 5.3 bug
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Feb 27, 2003 at 02:09:30PM -0500, Daniel
> > > Jacobowitz wrote:
> > > > > > > > On Thu, Feb 27, 2003 at 09:11:14PM +0300, Lev
> > > Assinovsky wrote:
> > > > > > > > > GNU gdb 5.3
> > > > > > > > > Copyright 2002 Free Software Foundation, Inc.
> > > > > > > > > GDB is free software, covered by the GNU
> General Public
> > > > > > > License, and you are
> > > > > > > > > welcome to change it and/or distribute copies
> of it under
> > > > > > > certain conditions.
> > > > > > > > > Type "show copying" to see the conditions.
> > > > > > > > > There is absolutely no warranty for GDB. Type "show
> > > > > > > warranty" for details.
> > > > > > > > > This GDB was configured as "i386-pc-solaris2.8"...
> > > > > > > > > (gdb) l
> > > > > > > > >
> > > > > > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > > > > > 0x08136671 in finish_block (symbol=0x6e5f5f3a,
> > > > > > > listhead=0x82241f4, old_blocks=0x3a787863,
> start=1634562671,
> > > > > > > > > end=1634562720, objfile=0x8263fe0) at
> buildsym.c:304
> > > > > > > > > 304 struct type *ftype =
> SYMBOL_TYPE (symbol);
> > > > > > > > > (gdb)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Any clue what might be the reason of gdb crash?
> > > > > > > >
> > > > > > > > OK, the value of "symbol" is obviously wrong.
> Could you
> > > > > > > privately send
> > > > > > > > me the binary? If that's not possible, at least a
> > > > > > > backtrace would be
> > > > > > > > useful...
> > > > > > >
> > > > > > >
> > > > > > > Lev,
> > > > > > >
> > > > > > > You're in luck, this has already been fixed. It
> appears to
> > > > > > > be a bug in
> > > > > > > the Sun compilers - it outputs end-of-function
> > > markers without a
> > > > > > > corresponding beginning-of-function marker. If you get a
> > > > > GDB snapshot
> > > > > > > from CVS (http://sources.redhat.com/gdb/) it
> should handle
> > > > > > > your program
> > > > > > > gracefully.
> > > > > > >
> > > > > > > --
> > > > > > > Daniel Jacobowitz
> > > > > > > MontaVista Software Debian
> > > > > GNU/Linux Developer
> > > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Daniel Jacobowitz
> > > > > MontaVista Software Debian
> > > GNU/Linux Developer
> > > > >
> > > >
> > >
> > > --
> > > Daniel Jacobowitz
> > > MontaVista Software Debian
> GNU/Linux Developer
> > >
> >
>
> --
> Daniel Jacobowitz
> MontaVista Software Debian GNU/Linux Developer
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: gdb 5.3 bug
@ 2003-03-07 14:35 Lev Assinovsky
0 siblings, 0 replies; 19+ messages in thread
From: Lev Assinovsky @ 2003-03-07 14:35 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb, Kevin Buettner
Thanks. Also
thank you and Kevin very much.
The fix is a really great event in our
team.
----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909
> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Friday, March 07, 2003 5:27 PM
> To: Lev Assinovsky
> Cc: gdb@sources.redhat.com; Kevin Buettner
> Subject: Re: gdb 5.3 bug
>
>
> On Fri, Mar 07, 2003 at 02:05:22PM +0300, Lev Assinovsky wrote:
> > I can's say that the bug fixed
> > but I found how to work around!!!
> > The problem was that gnu "ld" put "/usr/lib/libc.so.1" in place
> > of interpreter in executable.
> > If to use gcc option -Xlinker "--dynamic-linker" -Xlinker
> /usr/lib/ld.so.1
> > gdb works fine!
>
> Well, since current versons of the GNU tools won't do this, I think
> we're done. Great!
>
>
> --
> Daniel Jacobowitz
> MontaVista Software Debian GNU/Linux Developer
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 5.3 bug
2003-03-07 11:05 Lev Assinovsky
@ 2003-03-07 14:26 ` Daniel Jacobowitz
0 siblings, 0 replies; 19+ messages in thread
From: Daniel Jacobowitz @ 2003-03-07 14:26 UTC (permalink / raw)
To: Lev Assinovsky; +Cc: gdb, Kevin Buettner
On Fri, Mar 07, 2003 at 02:05:22PM +0300, Lev Assinovsky wrote:
> I can's say that the bug fixed
> but I found how to work around!!!
> The problem was that gnu "ld" put "/usr/lib/libc.so.1" in place
> of interpreter in executable.
> If to use gcc option -Xlinker "--dynamic-linker" -Xlinker /usr/lib/ld.so.1
> gdb works fine!
Well, since current versons of the GNU tools won't do this, I think
we're done. Great!
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: gdb 5.3 bug
@ 2003-03-07 11:05 Lev Assinovsky
2003-03-07 14:26 ` Daniel Jacobowitz
0 siblings, 1 reply; 19+ messages in thread
From: Lev Assinovsky @ 2003-03-07 11:05 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb, Kevin Buettner
I can's say that the bug fixed
but I found how to work around!!!
The problem was that gnu "ld" put "/usr/lib/libc.so.1" in place
of interpreter in executable.
If to use gcc option -Xlinker "--dynamic-linker" -Xlinker /usr/lib/ld.so.1
gdb works fine!
----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909
> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Wednesday, March 05, 2003 8:24 PM
> To: Lev Assinovsky
> Cc: gdb@sources.redhat.com
> Subject: Re: gdb 5.3 bug
>
>
> Solaris 2.8 shouldn't need solib-sunos, that's for something much
> older.
>
> ld.so.1 _should_ contain at least one of those symbols. I don't know
> which one is appropriate. It looks like on SPARC Solaris 2.7 it
> has rtld_db_dlactivity. Are you sure that "nm /lib/ld.so.1 | grep
> rtld_db_dlactivity" doesn't turn up anything?
>
> On Wed, Mar 05, 2003 at 08:13:14PM +0300, Lev Assinovsky wrote:
> > Also /usr/lib/ld.so.1 doesn't contain any symbol from your list:
> > "r_debug_state",
> > "_r_debug_state",
> > "_dl_debug_state",
> > "rtld_db_dlactivity",
> > "_rtld_debug_state",
> > ----
> > Lev Assinovsky
> > Aelita Software Corporation
> > O&S Core Division, Programmer
> > ICQ# 165072909
> >
> >
> > > -----Original Message-----
> > > From: Lev Assinovsky
> > > Sent: Wednesday, March 05, 2003 7:56 PM
> > > To: Daniel Jacobowitz
> > > Cc: gdb@sources.redhat.com
> > > Subject: RE: gdb 5.3 bug
> > >
> > >
> > > Is't is OK that configure didn't compile solib-sunos.c?
> > > I caught _DEBUG symbol there which /usr/lib/ld.so.1 also has.
> > >
> > > ----
> > > Lev Assinovsky
> > > Aelita Software Corporation
> > > O&S Core Division, Programmer
> > > ICQ# 165072909
> > >
> > >
> > > > -----Original Message-----
> > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > Sent: Wednesday, March 05, 2003 7:12 PM
> > > > To: Lev Assinovsky
> > > > Cc: gdb@sources.redhat.com
> > > > Subject: Re: gdb 5.3 bug
> > > >
> > > >
> > > > On Wed, Mar 05, 2003 at 07:07:41PM +0300, Lev Assinovsky wrote:
> > > > > Yes, it does:
> > > > > ----------
> > > > > (gdb) set stop-on-solib-events 1
> > > > > (gdb) r
> > > > > Starting program:
> > > > /export/home/lev/src/Installation/packages/Personal/LevAssinov
> > > > sky/virtfun/load
> > > > > warning: Unable to find dynamic linker breakpoint function.
> > > > > GDB will be unable to debug shared library initializers
> > > > > and track explicitly loaded dynamic code.
> > > > > Stopped due to shared library event
> > > > > -----------
> > > > > But what the warning mean?
> > > >
> > > > That's the problem. You'll have to figure out why the
> symbol it's
> > > > looking for is missing from your dynamic linker. It's
> > > looking for one
> > > > of these:
> > > > "r_debug_state",
> > > > "_r_debug_state",
> > > > "_dl_debug_state",
> > > > "rtld_db_dlactivity",
> > > > "_rtld_debug_state",
> > > >
> > > >
> > > > >
> > > > > Sincerely,
> > > > > ----
> > > > > Lev Assinovsky
> > > > > Aelita Software Corporation
> > > > > O&S Core Division, Programmer
> > > > > ICQ# 165072909
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > > > Sent: Wednesday, March 05, 2003 6:57 PM
> > > > > > To: Lev Assinovsky
> > > > > > Cc: gdb@sources.redhat.com
> > > > > > Subject: Re: gdb 5.3 bug
> > > > > >
> > > > > >
> > > > > > I don't know. Does "set stop-on-solib-events 1" cause
> > > > your program to
> > > > > > stop?
> > > > > >
> > > > > > On Wed, Mar 05, 2003 at 05:27:09PM +0300, Lev
> Assinovsky wrote:
> > > > > > > Daniel!
> > > > > > > I was wrong!
> > > > > > > I can step into the function of dynamic library if
> > > > > > > I run the command "sharedlibrary" before.
> > > > > > > Why are symbols coming in only after that command
> > > > > > > and auto-solib-add (=on) doesn't work?
> > > > > > >
> > > > > > > ----
> > > > > > > Lev Assinovsky
> > > > > > > Aelita Software Corporation
> > > > > > > O&S Core Division, Programmer
> > > > > > > ICQ# 165072909
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > > > > > Sent: Saturday, March 01, 2003 7:05 PM
> > > > > > > > To: Lev Assinovsky
> > > > > > > > Cc: gdb@sources.redhat.com
> > > > > > > > Subject: Re: gdb 5.3 bug
> > > > > > > >
> > > > > > > >
> > > > > > > > On Sat, Mar 01, 2003 at 06:59:45PM +0300, Lev
> > > > Assinovsky wrote:
> > > > > > > > > Dear Daniel!
> > > > > > > > > Thank you very match for your advise!
> > > > > > > > > Snapshot gdb+dejagnu-20030228 works just fine!
> > > > > > > > > Thank a lot all guys who is involved in gdb
> development.
> > > > > > > > > I am sorry but I have to bother you with another
> > > > gdb problem.
> > > > > > > > > The problem is I can't step into the function through
> > > > > > the pointer
> > > > > > > > > if the function resides in dynamically loaded
> > > shared object
> > > > > > > > (library).
> > > > > > > > > Here is the simple test case:
> > > > > > > >
> > > > > > > > Hmm. Your testcase works on GNU/Linux, so it must be
> > > > related to
> > > > > > > > i386-solaris shared library support. Maybe
> someone else
> > > > > > on the list
> > > > > > > > can help.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > 1. Shared object:
> > > > > > > > > ---------- cut here --------
> > > > > > > > > #include <iostream>
> > > > > > > > > using namespace std;
> > > > > > > > >
> > > > > > > > > extern "C" {
> > > > > > > > > void my_func()
> > > > > > > > > {
> > > > > > > > > cout << "This is my_func" << endl;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > }
> > > > > > > > > ---------- cut here --------
> > > > > > > > > 2. Main:
> > > > > > > > > #include <iostream>
> > > > > > > > > #include <memory>
> > > > > > > > > #include <dlfcn.h>
> > > > > > > > > #include <link.h>
> > > > > > > > >
> > > > > > > > > using namespace std;
> > > > > > > > >
> > > > > > > > > void * handle;
> > > > > > > > >
> > > > > > > > > typedef void ( *Func_t)();
> > > > > > > > >
> > > > > > > > > Func_t getFunc()
> > > > > > > > > {
> > > > > > > > > Func_t p = (Func_t)dlsym ( handle, "my_func" );
> > > > > > > > > if ( NULL == p )
> > > > > > > > > {
> > > > > > > > > cout << dlerror() << endl;
> > > > > > > > > exit(2);
> > > > > > > > > }
> > > > > > > > > return p;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > int main()
> > > > > > > > > {
> > > > > > > > > handle = (void*)
> > > > > > > > ::dlopen("./func_so/bin/i386-sun-solaris/func_so.so",
> > > > > > > > RTLD_NOW | RTLD_LOCAL | RTLD_GROUP);
> > > > > > > > > if (handle == NULL)
> > > > > > > > > {
> > > > > > > > > cout << dlerror() << endl;
> > > > > > > > > exit(2);
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > Func_t f = getFunc();
> > > > > > > > > f();
> > > > > > > > > }
> > > > > > > > > ---------- cut here --------
> > > > > > > > >
> > > > > > > > > This testcase works, but I can't step into f() (last
> > > > > > line) in gdb.
> > > > > > > > > Is it possible to work around or fix this problem?
> > > > > > > > > Thanks in advance!
> > > > > > > > >
> > > > > > > > > ----
> > > > > > > > > Lev Assinovsky
> > > > > > > > > Aelita Software Corporation
> > > > > > > > > O&S Core Division, Programmer
> > > > > > > > > ICQ# 165072909
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > > > > > > > Sent: Friday, February 28, 2003 8:19 PM
> > > > > > > > > > To: Lev Assinovsky; gdb@sources.redhat.com
> > > > > > > > > > Subject: Re: gdb 5.3 bug
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Thu, Feb 27, 2003 at 02:09:30PM -0500, Daniel
> > > > > > Jacobowitz wrote:
> > > > > > > > > > > On Thu, Feb 27, 2003 at 09:11:14PM +0300, Lev
> > > > > > Assinovsky wrote:
> > > > > > > > > > > > GNU gdb 5.3
> > > > > > > > > > > > Copyright 2002 Free Software Foundation, Inc.
> > > > > > > > > > > > GDB is free software, covered by the GNU
> > > > General Public
> > > > > > > > > > License, and you are
> > > > > > > > > > > > welcome to change it and/or distribute copies
> > > > of it under
> > > > > > > > > > certain conditions.
> > > > > > > > > > > > Type "show copying" to see the conditions.
> > > > > > > > > > > > There is absolutely no warranty for GDB.
> > > Type "show
> > > > > > > > > > warranty" for details.
> > > > > > > > > > > > This GDB was configured as
> "i386-pc-solaris2.8"...
> > > > > > > > > > > > (gdb) l
> > > > > > > > > > > >
> > > > > > > > > > > > Program received signal SIGSEGV,
> Segmentation fault.
> > > > > > > > > > > > 0x08136671 in finish_block (symbol=0x6e5f5f3a,
> > > > > > > > > > listhead=0x82241f4, old_blocks=0x3a787863,
> > > > start=1634562671,
> > > > > > > > > > > > end=1634562720, objfile=0x8263fe0) at
> > > > buildsym.c:304
> > > > > > > > > > > > 304 struct type *ftype =
> > > > SYMBOL_TYPE (symbol);
> > > > > > > > > > > > (gdb)
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Any clue what might be the reason of gdb crash?
> > > > > > > > > > >
> > > > > > > > > > > OK, the value of "symbol" is obviously wrong.
> > > > Could you
> > > > > > > > > > privately send
> > > > > > > > > > > me the binary? If that's not possible,
> at least a
> > > > > > > > > > backtrace would be
> > > > > > > > > > > useful...
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Lev,
> > > > > > > > > >
> > > > > > > > > > You're in luck, this has already been fixed. It
> > > > appears to
> > > > > > > > > > be a bug in
> > > > > > > > > > the Sun compilers - it outputs end-of-function
> > > > > > markers without a
> > > > > > > > > > corresponding beginning-of-function marker. If
> > > you get a
> > > > > > > > GDB snapshot
> > > > > > > > > > from CVS (http://sources.redhat.com/gdb/) it
> > > > should handle
> > > > > > > > > > your program
> > > > > > > > > > gracefully.
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Daniel Jacobowitz
> > > > > > > > > > MontaVista Software Debian
> > > > > > > > GNU/Linux Developer
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Daniel Jacobowitz
> > > > > > > > MontaVista Software Debian
> > > > > > GNU/Linux Developer
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Daniel Jacobowitz
> > > > > > MontaVista Software Debian
> > > > GNU/Linux Developer
> > > > > >
> > > > >
> > > >
> > > > --
> > > > Daniel Jacobowitz
> > > > MontaVista Software Debian
> > > GNU/Linux Developer
> > > >
> > >
> >
>
> --
> Daniel Jacobowitz
> MontaVista Software Debian GNU/Linux Developer
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 5.3 bug
2003-03-05 17:32 Lev Assinovsky
@ 2003-03-05 17:52 ` Kevin Buettner
0 siblings, 0 replies; 19+ messages in thread
From: Kevin Buettner @ 2003-03-05 17:52 UTC (permalink / raw)
To: Lev Assinovsky; +Cc: gdb
On Mar 5, 8:33pm, Lev Assinovsky wrote:
> You are right! I was wrong again.
> ld.so.1 HAS "rtld_db_dlactivity symbol"!
> Now I need to fugure out why doesn't gdb
> find it.
> May be you remember what gdb function should I stop in to
> start debug the gdb?
enable_break() in solib-svr4.c.
Kevin
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: gdb 5.3 bug
@ 2003-03-05 17:32 Lev Assinovsky
2003-03-05 17:52 ` Kevin Buettner
0 siblings, 1 reply; 19+ messages in thread
From: Lev Assinovsky @ 2003-03-05 17:32 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
You are right! I was wrong again.
ld.so.1 HAS "rtld_db_dlactivity symbol"!
Now I need to fugure out why doesn't gdb
find it.
May be you remember what gdb function should I stop in to
start debug the gdb?
----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909
> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Wednesday, March 05, 2003 8:24 PM
> To: Lev Assinovsky
> Cc: gdb@sources.redhat.com
> Subject: Re: gdb 5.3 bug
>
>
> Solaris 2.8 shouldn't need solib-sunos, that's for something much
> older.
>
> ld.so.1 _should_ contain at least one of those symbols. I don't know
> which one is appropriate. It looks like on SPARC Solaris 2.7 it
> has rtld_db_dlactivity. Are you sure that "nm /lib/ld.so.1 | grep
> rtld_db_dlactivity" doesn't turn up anything?
>
> On Wed, Mar 05, 2003 at 08:13:14PM +0300, Lev Assinovsky wrote:
> > Also /usr/lib/ld.so.1 doesn't contain any symbol from your list:
> > "r_debug_state",
> > "_r_debug_state",
> > "_dl_debug_state",
> > "rtld_db_dlactivity",
> > "_rtld_debug_state",
> > ----
> > Lev Assinovsky
> > Aelita Software Corporation
> > O&S Core Division, Programmer
> > ICQ# 165072909
> >
> >
> > > -----Original Message-----
> > > From: Lev Assinovsky
> > > Sent: Wednesday, March 05, 2003 7:56 PM
> > > To: Daniel Jacobowitz
> > > Cc: gdb@sources.redhat.com
> > > Subject: RE: gdb 5.3 bug
> > >
> > >
> > > Is't is OK that configure didn't compile solib-sunos.c?
> > > I caught _DEBUG symbol there which /usr/lib/ld.so.1 also has.
> > >
> > > ----
> > > Lev Assinovsky
> > > Aelita Software Corporation
> > > O&S Core Division, Programmer
> > > ICQ# 165072909
> > >
> > >
> > > > -----Original Message-----
> > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > Sent: Wednesday, March 05, 2003 7:12 PM
> > > > To: Lev Assinovsky
> > > > Cc: gdb@sources.redhat.com
> > > > Subject: Re: gdb 5.3 bug
> > > >
> > > >
> > > > On Wed, Mar 05, 2003 at 07:07:41PM +0300, Lev Assinovsky wrote:
> > > > > Yes, it does:
> > > > > ----------
> > > > > (gdb) set stop-on-solib-events 1
> > > > > (gdb) r
> > > > > Starting program:
> > > > /export/home/lev/src/Installation/packages/Personal/LevAssinov
> > > > sky/virtfun/load
> > > > > warning: Unable to find dynamic linker breakpoint function.
> > > > > GDB will be unable to debug shared library initializers
> > > > > and track explicitly loaded dynamic code.
> > > > > Stopped due to shared library event
> > > > > -----------
> > > > > But what the warning mean?
> > > >
> > > > That's the problem. You'll have to figure out why the
> symbol it's
> > > > looking for is missing from your dynamic linker. It's
> > > looking for one
> > > > of these:
> > > > "r_debug_state",
> > > > "_r_debug_state",
> > > > "_dl_debug_state",
> > > > "rtld_db_dlactivity",
> > > > "_rtld_debug_state",
> > > >
> > > >
> > > > >
> > > > > Sincerely,
> > > > > ----
> > > > > Lev Assinovsky
> > > > > Aelita Software Corporation
> > > > > O&S Core Division, Programmer
> > > > > ICQ# 165072909
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > > > Sent: Wednesday, March 05, 2003 6:57 PM
> > > > > > To: Lev Assinovsky
> > > > > > Cc: gdb@sources.redhat.com
> > > > > > Subject: Re: gdb 5.3 bug
> > > > > >
> > > > > >
> > > > > > I don't know. Does "set stop-on-solib-events 1" cause
> > > > your program to
> > > > > > stop?
> > > > > >
> > > > > > On Wed, Mar 05, 2003 at 05:27:09PM +0300, Lev
> Assinovsky wrote:
> > > > > > > Daniel!
> > > > > > > I was wrong!
> > > > > > > I can step into the function of dynamic library if
> > > > > > > I run the command "sharedlibrary" before.
> > > > > > > Why are symbols coming in only after that command
> > > > > > > and auto-solib-add (=on) doesn't work?
> > > > > > >
> > > > > > > ----
> > > > > > > Lev Assinovsky
> > > > > > > Aelita Software Corporation
> > > > > > > O&S Core Division, Programmer
> > > > > > > ICQ# 165072909
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > > > > > Sent: Saturday, March 01, 2003 7:05 PM
> > > > > > > > To: Lev Assinovsky
> > > > > > > > Cc: gdb@sources.redhat.com
> > > > > > > > Subject: Re: gdb 5.3 bug
> > > > > > > >
> > > > > > > >
> > > > > > > > On Sat, Mar 01, 2003 at 06:59:45PM +0300, Lev
> > > > Assinovsky wrote:
> > > > > > > > > Dear Daniel!
> > > > > > > > > Thank you very match for your advise!
> > > > > > > > > Snapshot gdb+dejagnu-20030228 works just fine!
> > > > > > > > > Thank a lot all guys who is involved in gdb
> development.
> > > > > > > > > I am sorry but I have to bother you with another
> > > > gdb problem.
> > > > > > > > > The problem is I can't step into the function through
> > > > > > the pointer
> > > > > > > > > if the function resides in dynamically loaded
> > > shared object
> > > > > > > > (library).
> > > > > > > > > Here is the simple test case:
> > > > > > > >
> > > > > > > > Hmm. Your testcase works on GNU/Linux, so it must be
> > > > related to
> > > > > > > > i386-solaris shared library support. Maybe
> someone else
> > > > > > on the list
> > > > > > > > can help.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > 1. Shared object:
> > > > > > > > > ---------- cut here --------
> > > > > > > > > #include <iostream>
> > > > > > > > > using namespace std;
> > > > > > > > >
> > > > > > > > > extern "C" {
> > > > > > > > > void my_func()
> > > > > > > > > {
> > > > > > > > > cout << "This is my_func" << endl;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > }
> > > > > > > > > ---------- cut here --------
> > > > > > > > > 2. Main:
> > > > > > > > > #include <iostream>
> > > > > > > > > #include <memory>
> > > > > > > > > #include <dlfcn.h>
> > > > > > > > > #include <link.h>
> > > > > > > > >
> > > > > > > > > using namespace std;
> > > > > > > > >
> > > > > > > > > void * handle;
> > > > > > > > >
> > > > > > > > > typedef void ( *Func_t)();
> > > > > > > > >
> > > > > > > > > Func_t getFunc()
> > > > > > > > > {
> > > > > > > > > Func_t p = (Func_t)dlsym ( handle, "my_func" );
> > > > > > > > > if ( NULL == p )
> > > > > > > > > {
> > > > > > > > > cout << dlerror() << endl;
> > > > > > > > > exit(2);
> > > > > > > > > }
> > > > > > > > > return p;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > int main()
> > > > > > > > > {
> > > > > > > > > handle = (void*)
> > > > > > > > ::dlopen("./func_so/bin/i386-sun-solaris/func_so.so",
> > > > > > > > RTLD_NOW | RTLD_LOCAL | RTLD_GROUP);
> > > > > > > > > if (handle == NULL)
> > > > > > > > > {
> > > > > > > > > cout << dlerror() << endl;
> > > > > > > > > exit(2);
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > Func_t f = getFunc();
> > > > > > > > > f();
> > > > > > > > > }
> > > > > > > > > ---------- cut here --------
> > > > > > > > >
> > > > > > > > > This testcase works, but I can't step into f() (last
> > > > > > line) in gdb.
> > > > > > > > > Is it possible to work around or fix this problem?
> > > > > > > > > Thanks in advance!
> > > > > > > > >
> > > > > > > > > ----
> > > > > > > > > Lev Assinovsky
> > > > > > > > > Aelita Software Corporation
> > > > > > > > > O&S Core Division, Programmer
> > > > > > > > > ICQ# 165072909
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > > > > > > > Sent: Friday, February 28, 2003 8:19 PM
> > > > > > > > > > To: Lev Assinovsky; gdb@sources.redhat.com
> > > > > > > > > > Subject: Re: gdb 5.3 bug
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Thu, Feb 27, 2003 at 02:09:30PM -0500, Daniel
> > > > > > Jacobowitz wrote:
> > > > > > > > > > > On Thu, Feb 27, 2003 at 09:11:14PM +0300, Lev
> > > > > > Assinovsky wrote:
> > > > > > > > > > > > GNU gdb 5.3
> > > > > > > > > > > > Copyright 2002 Free Software Foundation, Inc.
> > > > > > > > > > > > GDB is free software, covered by the GNU
> > > > General Public
> > > > > > > > > > License, and you are
> > > > > > > > > > > > welcome to change it and/or distribute copies
> > > > of it under
> > > > > > > > > > certain conditions.
> > > > > > > > > > > > Type "show copying" to see the conditions.
> > > > > > > > > > > > There is absolutely no warranty for GDB.
> > > Type "show
> > > > > > > > > > warranty" for details.
> > > > > > > > > > > > This GDB was configured as
> "i386-pc-solaris2.8"...
> > > > > > > > > > > > (gdb) l
> > > > > > > > > > > >
> > > > > > > > > > > > Program received signal SIGSEGV,
> Segmentation fault.
> > > > > > > > > > > > 0x08136671 in finish_block (symbol=0x6e5f5f3a,
> > > > > > > > > > listhead=0x82241f4, old_blocks=0x3a787863,
> > > > start=1634562671,
> > > > > > > > > > > > end=1634562720, objfile=0x8263fe0) at
> > > > buildsym.c:304
> > > > > > > > > > > > 304 struct type *ftype =
> > > > SYMBOL_TYPE (symbol);
> > > > > > > > > > > > (gdb)
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Any clue what might be the reason of gdb crash?
> > > > > > > > > > >
> > > > > > > > > > > OK, the value of "symbol" is obviously wrong.
> > > > Could you
> > > > > > > > > > privately send
> > > > > > > > > > > me the binary? If that's not possible,
> at least a
> > > > > > > > > > backtrace would be
> > > > > > > > > > > useful...
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Lev,
> > > > > > > > > >
> > > > > > > > > > You're in luck, this has already been fixed. It
> > > > appears to
> > > > > > > > > > be a bug in
> > > > > > > > > > the Sun compilers - it outputs end-of-function
> > > > > > markers without a
> > > > > > > > > > corresponding beginning-of-function marker. If
> > > you get a
> > > > > > > > GDB snapshot
> > > > > > > > > > from CVS (http://sources.redhat.com/gdb/) it
> > > > should handle
> > > > > > > > > > your program
> > > > > > > > > > gracefully.
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Daniel Jacobowitz
> > > > > > > > > > MontaVista Software Debian
> > > > > > > > GNU/Linux Developer
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Daniel Jacobowitz
> > > > > > > > MontaVista Software Debian
> > > > > > GNU/Linux Developer
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Daniel Jacobowitz
> > > > > > MontaVista Software Debian
> > > > GNU/Linux Developer
> > > > > >
> > > > >
> > > >
> > > > --
> > > > Daniel Jacobowitz
> > > > MontaVista Software Debian
> > > GNU/Linux Developer
> > > >
> > >
> >
>
> --
> Daniel Jacobowitz
> MontaVista Software Debian GNU/Linux Developer
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 5.3 bug
2003-03-05 17:12 Lev Assinovsky
@ 2003-03-05 17:23 ` Daniel Jacobowitz
0 siblings, 0 replies; 19+ messages in thread
From: Daniel Jacobowitz @ 2003-03-05 17:23 UTC (permalink / raw)
To: Lev Assinovsky; +Cc: gdb
Solaris 2.8 shouldn't need solib-sunos, that's for something much
older.
ld.so.1 _should_ contain at least one of those symbols. I don't know
which one is appropriate. It looks like on SPARC Solaris 2.7 it
has rtld_db_dlactivity. Are you sure that "nm /lib/ld.so.1 | grep
rtld_db_dlactivity" doesn't turn up anything?
On Wed, Mar 05, 2003 at 08:13:14PM +0300, Lev Assinovsky wrote:
> Also /usr/lib/ld.so.1 doesn't contain any symbol from your list:
> "r_debug_state",
> "_r_debug_state",
> "_dl_debug_state",
> "rtld_db_dlactivity",
> "_rtld_debug_state",
> ----
> Lev Assinovsky
> Aelita Software Corporation
> O&S Core Division, Programmer
> ICQ# 165072909
>
>
> > -----Original Message-----
> > From: Lev Assinovsky
> > Sent: Wednesday, March 05, 2003 7:56 PM
> > To: Daniel Jacobowitz
> > Cc: gdb@sources.redhat.com
> > Subject: RE: gdb 5.3 bug
> >
> >
> > Is't is OK that configure didn't compile solib-sunos.c?
> > I caught _DEBUG symbol there which /usr/lib/ld.so.1 also has.
> >
> > ----
> > Lev Assinovsky
> > Aelita Software Corporation
> > O&S Core Division, Programmer
> > ICQ# 165072909
> >
> >
> > > -----Original Message-----
> > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > Sent: Wednesday, March 05, 2003 7:12 PM
> > > To: Lev Assinovsky
> > > Cc: gdb@sources.redhat.com
> > > Subject: Re: gdb 5.3 bug
> > >
> > >
> > > On Wed, Mar 05, 2003 at 07:07:41PM +0300, Lev Assinovsky wrote:
> > > > Yes, it does:
> > > > ----------
> > > > (gdb) set stop-on-solib-events 1
> > > > (gdb) r
> > > > Starting program:
> > > /export/home/lev/src/Installation/packages/Personal/LevAssinov
> > > sky/virtfun/load
> > > > warning: Unable to find dynamic linker breakpoint function.
> > > > GDB will be unable to debug shared library initializers
> > > > and track explicitly loaded dynamic code.
> > > > Stopped due to shared library event
> > > > -----------
> > > > But what the warning mean?
> > >
> > > That's the problem. You'll have to figure out why the symbol it's
> > > looking for is missing from your dynamic linker. It's
> > looking for one
> > > of these:
> > > "r_debug_state",
> > > "_r_debug_state",
> > > "_dl_debug_state",
> > > "rtld_db_dlactivity",
> > > "_rtld_debug_state",
> > >
> > >
> > > >
> > > > Sincerely,
> > > > ----
> > > > Lev Assinovsky
> > > > Aelita Software Corporation
> > > > O&S Core Division, Programmer
> > > > ICQ# 165072909
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > > Sent: Wednesday, March 05, 2003 6:57 PM
> > > > > To: Lev Assinovsky
> > > > > Cc: gdb@sources.redhat.com
> > > > > Subject: Re: gdb 5.3 bug
> > > > >
> > > > >
> > > > > I don't know. Does "set stop-on-solib-events 1" cause
> > > your program to
> > > > > stop?
> > > > >
> > > > > On Wed, Mar 05, 2003 at 05:27:09PM +0300, Lev Assinovsky wrote:
> > > > > > Daniel!
> > > > > > I was wrong!
> > > > > > I can step into the function of dynamic library if
> > > > > > I run the command "sharedlibrary" before.
> > > > > > Why are symbols coming in only after that command
> > > > > > and auto-solib-add (=on) doesn't work?
> > > > > >
> > > > > > ----
> > > > > > Lev Assinovsky
> > > > > > Aelita Software Corporation
> > > > > > O&S Core Division, Programmer
> > > > > > ICQ# 165072909
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > > > > Sent: Saturday, March 01, 2003 7:05 PM
> > > > > > > To: Lev Assinovsky
> > > > > > > Cc: gdb@sources.redhat.com
> > > > > > > Subject: Re: gdb 5.3 bug
> > > > > > >
> > > > > > >
> > > > > > > On Sat, Mar 01, 2003 at 06:59:45PM +0300, Lev
> > > Assinovsky wrote:
> > > > > > > > Dear Daniel!
> > > > > > > > Thank you very match for your advise!
> > > > > > > > Snapshot gdb+dejagnu-20030228 works just fine!
> > > > > > > > Thank a lot all guys who is involved in gdb development.
> > > > > > > > I am sorry but I have to bother you with another
> > > gdb problem.
> > > > > > > > The problem is I can't step into the function through
> > > > > the pointer
> > > > > > > > if the function resides in dynamically loaded
> > shared object
> > > > > > > (library).
> > > > > > > > Here is the simple test case:
> > > > > > >
> > > > > > > Hmm. Your testcase works on GNU/Linux, so it must be
> > > related to
> > > > > > > i386-solaris shared library support. Maybe someone else
> > > > > on the list
> > > > > > > can help.
> > > > > > >
> > > > > > > >
> > > > > > > > 1. Shared object:
> > > > > > > > ---------- cut here --------
> > > > > > > > #include <iostream>
> > > > > > > > using namespace std;
> > > > > > > >
> > > > > > > > extern "C" {
> > > > > > > > void my_func()
> > > > > > > > {
> > > > > > > > cout << "This is my_func" << endl;
> > > > > > > > }
> > > > > > > >
> > > > > > > > }
> > > > > > > > ---------- cut here --------
> > > > > > > > 2. Main:
> > > > > > > > #include <iostream>
> > > > > > > > #include <memory>
> > > > > > > > #include <dlfcn.h>
> > > > > > > > #include <link.h>
> > > > > > > >
> > > > > > > > using namespace std;
> > > > > > > >
> > > > > > > > void * handle;
> > > > > > > >
> > > > > > > > typedef void ( *Func_t)();
> > > > > > > >
> > > > > > > > Func_t getFunc()
> > > > > > > > {
> > > > > > > > Func_t p = (Func_t)dlsym ( handle, "my_func" );
> > > > > > > > if ( NULL == p )
> > > > > > > > {
> > > > > > > > cout << dlerror() << endl;
> > > > > > > > exit(2);
> > > > > > > > }
> > > > > > > > return p;
> > > > > > > > }
> > > > > > > >
> > > > > > > > int main()
> > > > > > > > {
> > > > > > > > handle = (void*)
> > > > > > > ::dlopen("./func_so/bin/i386-sun-solaris/func_so.so",
> > > > > > > RTLD_NOW | RTLD_LOCAL | RTLD_GROUP);
> > > > > > > > if (handle == NULL)
> > > > > > > > {
> > > > > > > > cout << dlerror() << endl;
> > > > > > > > exit(2);
> > > > > > > > }
> > > > > > > >
> > > > > > > > Func_t f = getFunc();
> > > > > > > > f();
> > > > > > > > }
> > > > > > > > ---------- cut here --------
> > > > > > > >
> > > > > > > > This testcase works, but I can't step into f() (last
> > > > > line) in gdb.
> > > > > > > > Is it possible to work around or fix this problem?
> > > > > > > > Thanks in advance!
> > > > > > > >
> > > > > > > > ----
> > > > > > > > Lev Assinovsky
> > > > > > > > Aelita Software Corporation
> > > > > > > > O&S Core Division, Programmer
> > > > > > > > ICQ# 165072909
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > > > > > > Sent: Friday, February 28, 2003 8:19 PM
> > > > > > > > > To: Lev Assinovsky; gdb@sources.redhat.com
> > > > > > > > > Subject: Re: gdb 5.3 bug
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Thu, Feb 27, 2003 at 02:09:30PM -0500, Daniel
> > > > > Jacobowitz wrote:
> > > > > > > > > > On Thu, Feb 27, 2003 at 09:11:14PM +0300, Lev
> > > > > Assinovsky wrote:
> > > > > > > > > > > GNU gdb 5.3
> > > > > > > > > > > Copyright 2002 Free Software Foundation, Inc.
> > > > > > > > > > > GDB is free software, covered by the GNU
> > > General Public
> > > > > > > > > License, and you are
> > > > > > > > > > > welcome to change it and/or distribute copies
> > > of it under
> > > > > > > > > certain conditions.
> > > > > > > > > > > Type "show copying" to see the conditions.
> > > > > > > > > > > There is absolutely no warranty for GDB.
> > Type "show
> > > > > > > > > warranty" for details.
> > > > > > > > > > > This GDB was configured as "i386-pc-solaris2.8"...
> > > > > > > > > > > (gdb) l
> > > > > > > > > > >
> > > > > > > > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > > > > > > > 0x08136671 in finish_block (symbol=0x6e5f5f3a,
> > > > > > > > > listhead=0x82241f4, old_blocks=0x3a787863,
> > > start=1634562671,
> > > > > > > > > > > end=1634562720, objfile=0x8263fe0) at
> > > buildsym.c:304
> > > > > > > > > > > 304 struct type *ftype =
> > > SYMBOL_TYPE (symbol);
> > > > > > > > > > > (gdb)
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Any clue what might be the reason of gdb crash?
> > > > > > > > > >
> > > > > > > > > > OK, the value of "symbol" is obviously wrong.
> > > Could you
> > > > > > > > > privately send
> > > > > > > > > > me the binary? If that's not possible, at least a
> > > > > > > > > backtrace would be
> > > > > > > > > > useful...
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Lev,
> > > > > > > > >
> > > > > > > > > You're in luck, this has already been fixed. It
> > > appears to
> > > > > > > > > be a bug in
> > > > > > > > > the Sun compilers - it outputs end-of-function
> > > > > markers without a
> > > > > > > > > corresponding beginning-of-function marker. If
> > you get a
> > > > > > > GDB snapshot
> > > > > > > > > from CVS (http://sources.redhat.com/gdb/) it
> > > should handle
> > > > > > > > > your program
> > > > > > > > > gracefully.
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Daniel Jacobowitz
> > > > > > > > > MontaVista Software Debian
> > > > > > > GNU/Linux Developer
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Daniel Jacobowitz
> > > > > > > MontaVista Software Debian
> > > > > GNU/Linux Developer
> > > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Daniel Jacobowitz
> > > > > MontaVista Software Debian
> > > GNU/Linux Developer
> > > > >
> > > >
> > >
> > > --
> > > Daniel Jacobowitz
> > > MontaVista Software Debian
> > GNU/Linux Developer
> > >
> >
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: gdb 5.3 bug
@ 2003-03-05 17:12 Lev Assinovsky
2003-03-05 17:23 ` Daniel Jacobowitz
0 siblings, 1 reply; 19+ messages in thread
From: Lev Assinovsky @ 2003-03-05 17:12 UTC (permalink / raw)
To: Lev Assinovsky, Daniel Jacobowitz; +Cc: gdb
Also /usr/lib/ld.so.1 doesn't contain any symbol from your list:
"r_debug_state",
"_r_debug_state",
"_dl_debug_state",
"rtld_db_dlactivity",
"_rtld_debug_state",
----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909
> -----Original Message-----
> From: Lev Assinovsky
> Sent: Wednesday, March 05, 2003 7:56 PM
> To: Daniel Jacobowitz
> Cc: gdb@sources.redhat.com
> Subject: RE: gdb 5.3 bug
>
>
> Is't is OK that configure didn't compile solib-sunos.c?
> I caught _DEBUG symbol there which /usr/lib/ld.so.1 also has.
>
> ----
> Lev Assinovsky
> Aelita Software Corporation
> O&S Core Division, Programmer
> ICQ# 165072909
>
>
> > -----Original Message-----
> > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > Sent: Wednesday, March 05, 2003 7:12 PM
> > To: Lev Assinovsky
> > Cc: gdb@sources.redhat.com
> > Subject: Re: gdb 5.3 bug
> >
> >
> > On Wed, Mar 05, 2003 at 07:07:41PM +0300, Lev Assinovsky wrote:
> > > Yes, it does:
> > > ----------
> > > (gdb) set stop-on-solib-events 1
> > > (gdb) r
> > > Starting program:
> > /export/home/lev/src/Installation/packages/Personal/LevAssinov
> > sky/virtfun/load
> > > warning: Unable to find dynamic linker breakpoint function.
> > > GDB will be unable to debug shared library initializers
> > > and track explicitly loaded dynamic code.
> > > Stopped due to shared library event
> > > -----------
> > > But what the warning mean?
> >
> > That's the problem. You'll have to figure out why the symbol it's
> > looking for is missing from your dynamic linker. It's
> looking for one
> > of these:
> > "r_debug_state",
> > "_r_debug_state",
> > "_dl_debug_state",
> > "rtld_db_dlactivity",
> > "_rtld_debug_state",
> >
> >
> > >
> > > Sincerely,
> > > ----
> > > Lev Assinovsky
> > > Aelita Software Corporation
> > > O&S Core Division, Programmer
> > > ICQ# 165072909
> > >
> > >
> > > > -----Original Message-----
> > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > Sent: Wednesday, March 05, 2003 6:57 PM
> > > > To: Lev Assinovsky
> > > > Cc: gdb@sources.redhat.com
> > > > Subject: Re: gdb 5.3 bug
> > > >
> > > >
> > > > I don't know. Does "set stop-on-solib-events 1" cause
> > your program to
> > > > stop?
> > > >
> > > > On Wed, Mar 05, 2003 at 05:27:09PM +0300, Lev Assinovsky wrote:
> > > > > Daniel!
> > > > > I was wrong!
> > > > > I can step into the function of dynamic library if
> > > > > I run the command "sharedlibrary" before.
> > > > > Why are symbols coming in only after that command
> > > > > and auto-solib-add (=on) doesn't work?
> > > > >
> > > > > ----
> > > > > Lev Assinovsky
> > > > > Aelita Software Corporation
> > > > > O&S Core Division, Programmer
> > > > > ICQ# 165072909
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > > > Sent: Saturday, March 01, 2003 7:05 PM
> > > > > > To: Lev Assinovsky
> > > > > > Cc: gdb@sources.redhat.com
> > > > > > Subject: Re: gdb 5.3 bug
> > > > > >
> > > > > >
> > > > > > On Sat, Mar 01, 2003 at 06:59:45PM +0300, Lev
> > Assinovsky wrote:
> > > > > > > Dear Daniel!
> > > > > > > Thank you very match for your advise!
> > > > > > > Snapshot gdb+dejagnu-20030228 works just fine!
> > > > > > > Thank a lot all guys who is involved in gdb development.
> > > > > > > I am sorry but I have to bother you with another
> > gdb problem.
> > > > > > > The problem is I can't step into the function through
> > > > the pointer
> > > > > > > if the function resides in dynamically loaded
> shared object
> > > > > > (library).
> > > > > > > Here is the simple test case:
> > > > > >
> > > > > > Hmm. Your testcase works on GNU/Linux, so it must be
> > related to
> > > > > > i386-solaris shared library support. Maybe someone else
> > > > on the list
> > > > > > can help.
> > > > > >
> > > > > > >
> > > > > > > 1. Shared object:
> > > > > > > ---------- cut here --------
> > > > > > > #include <iostream>
> > > > > > > using namespace std;
> > > > > > >
> > > > > > > extern "C" {
> > > > > > > void my_func()
> > > > > > > {
> > > > > > > cout << "This is my_func" << endl;
> > > > > > > }
> > > > > > >
> > > > > > > }
> > > > > > > ---------- cut here --------
> > > > > > > 2. Main:
> > > > > > > #include <iostream>
> > > > > > > #include <memory>
> > > > > > > #include <dlfcn.h>
> > > > > > > #include <link.h>
> > > > > > >
> > > > > > > using namespace std;
> > > > > > >
> > > > > > > void * handle;
> > > > > > >
> > > > > > > typedef void ( *Func_t)();
> > > > > > >
> > > > > > > Func_t getFunc()
> > > > > > > {
> > > > > > > Func_t p = (Func_t)dlsym ( handle, "my_func" );
> > > > > > > if ( NULL == p )
> > > > > > > {
> > > > > > > cout << dlerror() << endl;
> > > > > > > exit(2);
> > > > > > > }
> > > > > > > return p;
> > > > > > > }
> > > > > > >
> > > > > > > int main()
> > > > > > > {
> > > > > > > handle = (void*)
> > > > > > ::dlopen("./func_so/bin/i386-sun-solaris/func_so.so",
> > > > > > RTLD_NOW | RTLD_LOCAL | RTLD_GROUP);
> > > > > > > if (handle == NULL)
> > > > > > > {
> > > > > > > cout << dlerror() << endl;
> > > > > > > exit(2);
> > > > > > > }
> > > > > > >
> > > > > > > Func_t f = getFunc();
> > > > > > > f();
> > > > > > > }
> > > > > > > ---------- cut here --------
> > > > > > >
> > > > > > > This testcase works, but I can't step into f() (last
> > > > line) in gdb.
> > > > > > > Is it possible to work around or fix this problem?
> > > > > > > Thanks in advance!
> > > > > > >
> > > > > > > ----
> > > > > > > Lev Assinovsky
> > > > > > > Aelita Software Corporation
> > > > > > > O&S Core Division, Programmer
> > > > > > > ICQ# 165072909
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > > > > > Sent: Friday, February 28, 2003 8:19 PM
> > > > > > > > To: Lev Assinovsky; gdb@sources.redhat.com
> > > > > > > > Subject: Re: gdb 5.3 bug
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thu, Feb 27, 2003 at 02:09:30PM -0500, Daniel
> > > > Jacobowitz wrote:
> > > > > > > > > On Thu, Feb 27, 2003 at 09:11:14PM +0300, Lev
> > > > Assinovsky wrote:
> > > > > > > > > > GNU gdb 5.3
> > > > > > > > > > Copyright 2002 Free Software Foundation, Inc.
> > > > > > > > > > GDB is free software, covered by the GNU
> > General Public
> > > > > > > > License, and you are
> > > > > > > > > > welcome to change it and/or distribute copies
> > of it under
> > > > > > > > certain conditions.
> > > > > > > > > > Type "show copying" to see the conditions.
> > > > > > > > > > There is absolutely no warranty for GDB.
> Type "show
> > > > > > > > warranty" for details.
> > > > > > > > > > This GDB was configured as "i386-pc-solaris2.8"...
> > > > > > > > > > (gdb) l
> > > > > > > > > >
> > > > > > > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > > > > > > 0x08136671 in finish_block (symbol=0x6e5f5f3a,
> > > > > > > > listhead=0x82241f4, old_blocks=0x3a787863,
> > start=1634562671,
> > > > > > > > > > end=1634562720, objfile=0x8263fe0) at
> > buildsym.c:304
> > > > > > > > > > 304 struct type *ftype =
> > SYMBOL_TYPE (symbol);
> > > > > > > > > > (gdb)
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Any clue what might be the reason of gdb crash?
> > > > > > > > >
> > > > > > > > > OK, the value of "symbol" is obviously wrong.
> > Could you
> > > > > > > > privately send
> > > > > > > > > me the binary? If that's not possible, at least a
> > > > > > > > backtrace would be
> > > > > > > > > useful...
> > > > > > > >
> > > > > > > >
> > > > > > > > Lev,
> > > > > > > >
> > > > > > > > You're in luck, this has already been fixed. It
> > appears to
> > > > > > > > be a bug in
> > > > > > > > the Sun compilers - it outputs end-of-function
> > > > markers without a
> > > > > > > > corresponding beginning-of-function marker. If
> you get a
> > > > > > GDB snapshot
> > > > > > > > from CVS (http://sources.redhat.com/gdb/) it
> > should handle
> > > > > > > > your program
> > > > > > > > gracefully.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Daniel Jacobowitz
> > > > > > > > MontaVista Software Debian
> > > > > > GNU/Linux Developer
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Daniel Jacobowitz
> > > > > > MontaVista Software Debian
> > > > GNU/Linux Developer
> > > > > >
> > > > >
> > > >
> > > > --
> > > > Daniel Jacobowitz
> > > > MontaVista Software Debian
> > GNU/Linux Developer
> > > >
> > >
> >
> > --
> > Daniel Jacobowitz
> > MontaVista Software Debian
> GNU/Linux Developer
> >
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 5.3 bug
2003-03-05 16:06 Lev Assinovsky
@ 2003-03-05 16:12 ` Daniel Jacobowitz
0 siblings, 0 replies; 19+ messages in thread
From: Daniel Jacobowitz @ 2003-03-05 16:12 UTC (permalink / raw)
To: Lev Assinovsky; +Cc: gdb
On Wed, Mar 05, 2003 at 07:07:41PM +0300, Lev Assinovsky wrote:
> Yes, it does:
> ----------
> (gdb) set stop-on-solib-events 1
> (gdb) r
> Starting program: /export/home/lev/src/Installation/packages/Personal/LevAssinovsky/virtfun/load
> warning: Unable to find dynamic linker breakpoint function.
> GDB will be unable to debug shared library initializers
> and track explicitly loaded dynamic code.
> Stopped due to shared library event
> -----------
> But what the warning mean?
That's the problem. You'll have to figure out why the symbol it's
looking for is missing from your dynamic linker. It's looking for one
of these:
"r_debug_state",
"_r_debug_state",
"_dl_debug_state",
"rtld_db_dlactivity",
"_rtld_debug_state",
>
> Sincerely,
> ----
> Lev Assinovsky
> Aelita Software Corporation
> O&S Core Division, Programmer
> ICQ# 165072909
>
>
> > -----Original Message-----
> > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > Sent: Wednesday, March 05, 2003 6:57 PM
> > To: Lev Assinovsky
> > Cc: gdb@sources.redhat.com
> > Subject: Re: gdb 5.3 bug
> >
> >
> > I don't know. Does "set stop-on-solib-events 1" cause your program to
> > stop?
> >
> > On Wed, Mar 05, 2003 at 05:27:09PM +0300, Lev Assinovsky wrote:
> > > Daniel!
> > > I was wrong!
> > > I can step into the function of dynamic library if
> > > I run the command "sharedlibrary" before.
> > > Why are symbols coming in only after that command
> > > and auto-solib-add (=on) doesn't work?
> > >
> > > ----
> > > Lev Assinovsky
> > > Aelita Software Corporation
> > > O&S Core Division, Programmer
> > > ICQ# 165072909
> > >
> > >
> > > > -----Original Message-----
> > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > Sent: Saturday, March 01, 2003 7:05 PM
> > > > To: Lev Assinovsky
> > > > Cc: gdb@sources.redhat.com
> > > > Subject: Re: gdb 5.3 bug
> > > >
> > > >
> > > > On Sat, Mar 01, 2003 at 06:59:45PM +0300, Lev Assinovsky wrote:
> > > > > Dear Daniel!
> > > > > Thank you very match for your advise!
> > > > > Snapshot gdb+dejagnu-20030228 works just fine!
> > > > > Thank a lot all guys who is involved in gdb development.
> > > > > I am sorry but I have to bother you with another gdb problem.
> > > > > The problem is I can't step into the function through
> > the pointer
> > > > > if the function resides in dynamically loaded shared object
> > > > (library).
> > > > > Here is the simple test case:
> > > >
> > > > Hmm. Your testcase works on GNU/Linux, so it must be related to
> > > > i386-solaris shared library support. Maybe someone else
> > on the list
> > > > can help.
> > > >
> > > > >
> > > > > 1. Shared object:
> > > > > ---------- cut here --------
> > > > > #include <iostream>
> > > > > using namespace std;
> > > > >
> > > > > extern "C" {
> > > > > void my_func()
> > > > > {
> > > > > cout << "This is my_func" << endl;
> > > > > }
> > > > >
> > > > > }
> > > > > ---------- cut here --------
> > > > > 2. Main:
> > > > > #include <iostream>
> > > > > #include <memory>
> > > > > #include <dlfcn.h>
> > > > > #include <link.h>
> > > > >
> > > > > using namespace std;
> > > > >
> > > > > void * handle;
> > > > >
> > > > > typedef void ( *Func_t)();
> > > > >
> > > > > Func_t getFunc()
> > > > > {
> > > > > Func_t p = (Func_t)dlsym ( handle, "my_func" );
> > > > > if ( NULL == p )
> > > > > {
> > > > > cout << dlerror() << endl;
> > > > > exit(2);
> > > > > }
> > > > > return p;
> > > > > }
> > > > >
> > > > > int main()
> > > > > {
> > > > > handle = (void*)
> > > > ::dlopen("./func_so/bin/i386-sun-solaris/func_so.so",
> > > > RTLD_NOW | RTLD_LOCAL | RTLD_GROUP);
> > > > > if (handle == NULL)
> > > > > {
> > > > > cout << dlerror() << endl;
> > > > > exit(2);
> > > > > }
> > > > >
> > > > > Func_t f = getFunc();
> > > > > f();
> > > > > }
> > > > > ---------- cut here --------
> > > > >
> > > > > This testcase works, but I can't step into f() (last
> > line) in gdb.
> > > > > Is it possible to work around or fix this problem?
> > > > > Thanks in advance!
> > > > >
> > > > > ----
> > > > > Lev Assinovsky
> > > > > Aelita Software Corporation
> > > > > O&S Core Division, Programmer
> > > > > ICQ# 165072909
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > > > Sent: Friday, February 28, 2003 8:19 PM
> > > > > > To: Lev Assinovsky; gdb@sources.redhat.com
> > > > > > Subject: Re: gdb 5.3 bug
> > > > > >
> > > > > >
> > > > > > On Thu, Feb 27, 2003 at 02:09:30PM -0500, Daniel
> > Jacobowitz wrote:
> > > > > > > On Thu, Feb 27, 2003 at 09:11:14PM +0300, Lev
> > Assinovsky wrote:
> > > > > > > > GNU gdb 5.3
> > > > > > > > Copyright 2002 Free Software Foundation, Inc.
> > > > > > > > GDB is free software, covered by the GNU General Public
> > > > > > License, and you are
> > > > > > > > welcome to change it and/or distribute copies of it under
> > > > > > certain conditions.
> > > > > > > > Type "show copying" to see the conditions.
> > > > > > > > There is absolutely no warranty for GDB. Type "show
> > > > > > warranty" for details.
> > > > > > > > This GDB was configured as "i386-pc-solaris2.8"...
> > > > > > > > (gdb) l
> > > > > > > >
> > > > > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > > > > 0x08136671 in finish_block (symbol=0x6e5f5f3a,
> > > > > > listhead=0x82241f4, old_blocks=0x3a787863, start=1634562671,
> > > > > > > > end=1634562720, objfile=0x8263fe0) at buildsym.c:304
> > > > > > > > 304 struct type *ftype = SYMBOL_TYPE (symbol);
> > > > > > > > (gdb)
> > > > > > > >
> > > > > > > >
> > > > > > > > Any clue what might be the reason of gdb crash?
> > > > > > >
> > > > > > > OK, the value of "symbol" is obviously wrong. Could you
> > > > > > privately send
> > > > > > > me the binary? If that's not possible, at least a
> > > > > > backtrace would be
> > > > > > > useful...
> > > > > >
> > > > > >
> > > > > > Lev,
> > > > > >
> > > > > > You're in luck, this has already been fixed. It appears to
> > > > > > be a bug in
> > > > > > the Sun compilers - it outputs end-of-function
> > markers without a
> > > > > > corresponding beginning-of-function marker. If you get a
> > > > GDB snapshot
> > > > > > from CVS (http://sources.redhat.com/gdb/) it should handle
> > > > > > your program
> > > > > > gracefully.
> > > > > >
> > > > > > --
> > > > > > Daniel Jacobowitz
> > > > > > MontaVista Software Debian
> > > > GNU/Linux Developer
> > > > > >
> > > > >
> > > >
> > > > --
> > > > Daniel Jacobowitz
> > > > MontaVista Software Debian
> > GNU/Linux Developer
> > > >
> > >
> >
> > --
> > Daniel Jacobowitz
> > MontaVista Software Debian GNU/Linux Developer
> >
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: gdb 5.3 bug
@ 2003-03-05 16:06 Lev Assinovsky
2003-03-05 16:12 ` Daniel Jacobowitz
0 siblings, 1 reply; 19+ messages in thread
From: Lev Assinovsky @ 2003-03-05 16:06 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
Yes, it does:
----------
(gdb) set stop-on-solib-events 1
(gdb) r
Starting program: /export/home/lev/src/Installation/packages/Personal/LevAssinovsky/virtfun/load
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Stopped due to shared library event
-----------
But what the warning mean?
Sincerely,
----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909
> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Wednesday, March 05, 2003 6:57 PM
> To: Lev Assinovsky
> Cc: gdb@sources.redhat.com
> Subject: Re: gdb 5.3 bug
>
>
> I don't know. Does "set stop-on-solib-events 1" cause your program to
> stop?
>
> On Wed, Mar 05, 2003 at 05:27:09PM +0300, Lev Assinovsky wrote:
> > Daniel!
> > I was wrong!
> > I can step into the function of dynamic library if
> > I run the command "sharedlibrary" before.
> > Why are symbols coming in only after that command
> > and auto-solib-add (=on) doesn't work?
> >
> > ----
> > Lev Assinovsky
> > Aelita Software Corporation
> > O&S Core Division, Programmer
> > ICQ# 165072909
> >
> >
> > > -----Original Message-----
> > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > Sent: Saturday, March 01, 2003 7:05 PM
> > > To: Lev Assinovsky
> > > Cc: gdb@sources.redhat.com
> > > Subject: Re: gdb 5.3 bug
> > >
> > >
> > > On Sat, Mar 01, 2003 at 06:59:45PM +0300, Lev Assinovsky wrote:
> > > > Dear Daniel!
> > > > Thank you very match for your advise!
> > > > Snapshot gdb+dejagnu-20030228 works just fine!
> > > > Thank a lot all guys who is involved in gdb development.
> > > > I am sorry but I have to bother you with another gdb problem.
> > > > The problem is I can't step into the function through
> the pointer
> > > > if the function resides in dynamically loaded shared object
> > > (library).
> > > > Here is the simple test case:
> > >
> > > Hmm. Your testcase works on GNU/Linux, so it must be related to
> > > i386-solaris shared library support. Maybe someone else
> on the list
> > > can help.
> > >
> > > >
> > > > 1. Shared object:
> > > > ---------- cut here --------
> > > > #include <iostream>
> > > > using namespace std;
> > > >
> > > > extern "C" {
> > > > void my_func()
> > > > {
> > > > cout << "This is my_func" << endl;
> > > > }
> > > >
> > > > }
> > > > ---------- cut here --------
> > > > 2. Main:
> > > > #include <iostream>
> > > > #include <memory>
> > > > #include <dlfcn.h>
> > > > #include <link.h>
> > > >
> > > > using namespace std;
> > > >
> > > > void * handle;
> > > >
> > > > typedef void ( *Func_t)();
> > > >
> > > > Func_t getFunc()
> > > > {
> > > > Func_t p = (Func_t)dlsym ( handle, "my_func" );
> > > > if ( NULL == p )
> > > > {
> > > > cout << dlerror() << endl;
> > > > exit(2);
> > > > }
> > > > return p;
> > > > }
> > > >
> > > > int main()
> > > > {
> > > > handle = (void*)
> > > ::dlopen("./func_so/bin/i386-sun-solaris/func_so.so",
> > > RTLD_NOW | RTLD_LOCAL | RTLD_GROUP);
> > > > if (handle == NULL)
> > > > {
> > > > cout << dlerror() << endl;
> > > > exit(2);
> > > > }
> > > >
> > > > Func_t f = getFunc();
> > > > f();
> > > > }
> > > > ---------- cut here --------
> > > >
> > > > This testcase works, but I can't step into f() (last
> line) in gdb.
> > > > Is it possible to work around or fix this problem?
> > > > Thanks in advance!
> > > >
> > > > ----
> > > > Lev Assinovsky
> > > > Aelita Software Corporation
> > > > O&S Core Division, Programmer
> > > > ICQ# 165072909
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > > Sent: Friday, February 28, 2003 8:19 PM
> > > > > To: Lev Assinovsky; gdb@sources.redhat.com
> > > > > Subject: Re: gdb 5.3 bug
> > > > >
> > > > >
> > > > > On Thu, Feb 27, 2003 at 02:09:30PM -0500, Daniel
> Jacobowitz wrote:
> > > > > > On Thu, Feb 27, 2003 at 09:11:14PM +0300, Lev
> Assinovsky wrote:
> > > > > > > GNU gdb 5.3
> > > > > > > Copyright 2002 Free Software Foundation, Inc.
> > > > > > > GDB is free software, covered by the GNU General Public
> > > > > License, and you are
> > > > > > > welcome to change it and/or distribute copies of it under
> > > > > certain conditions.
> > > > > > > Type "show copying" to see the conditions.
> > > > > > > There is absolutely no warranty for GDB. Type "show
> > > > > warranty" for details.
> > > > > > > This GDB was configured as "i386-pc-solaris2.8"...
> > > > > > > (gdb) l
> > > > > > >
> > > > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > > > 0x08136671 in finish_block (symbol=0x6e5f5f3a,
> > > > > listhead=0x82241f4, old_blocks=0x3a787863, start=1634562671,
> > > > > > > end=1634562720, objfile=0x8263fe0) at buildsym.c:304
> > > > > > > 304 struct type *ftype = SYMBOL_TYPE (symbol);
> > > > > > > (gdb)
> > > > > > >
> > > > > > >
> > > > > > > Any clue what might be the reason of gdb crash?
> > > > > >
> > > > > > OK, the value of "symbol" is obviously wrong. Could you
> > > > > privately send
> > > > > > me the binary? If that's not possible, at least a
> > > > > backtrace would be
> > > > > > useful...
> > > > >
> > > > >
> > > > > Lev,
> > > > >
> > > > > You're in luck, this has already been fixed. It appears to
> > > > > be a bug in
> > > > > the Sun compilers - it outputs end-of-function
> markers without a
> > > > > corresponding beginning-of-function marker. If you get a
> > > GDB snapshot
> > > > > from CVS (http://sources.redhat.com/gdb/) it should handle
> > > > > your program
> > > > > gracefully.
> > > > >
> > > > > --
> > > > > Daniel Jacobowitz
> > > > > MontaVista Software Debian
> > > GNU/Linux Developer
> > > > >
> > > >
> > >
> > > --
> > > Daniel Jacobowitz
> > > MontaVista Software Debian
> GNU/Linux Developer
> > >
> >
>
> --
> Daniel Jacobowitz
> MontaVista Software Debian GNU/Linux Developer
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 5.3 bug
2003-03-05 14:27 Lev Assinovsky
@ 2003-03-05 15:57 ` Daniel Jacobowitz
0 siblings, 0 replies; 19+ messages in thread
From: Daniel Jacobowitz @ 2003-03-05 15:57 UTC (permalink / raw)
To: Lev Assinovsky; +Cc: gdb
I don't know. Does "set stop-on-solib-events 1" cause your program to
stop?
On Wed, Mar 05, 2003 at 05:27:09PM +0300, Lev Assinovsky wrote:
> Daniel!
> I was wrong!
> I can step into the function of dynamic library if
> I run the command "sharedlibrary" before.
> Why are symbols coming in only after that command
> and auto-solib-add (=on) doesn't work?
>
> ----
> Lev Assinovsky
> Aelita Software Corporation
> O&S Core Division, Programmer
> ICQ# 165072909
>
>
> > -----Original Message-----
> > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > Sent: Saturday, March 01, 2003 7:05 PM
> > To: Lev Assinovsky
> > Cc: gdb@sources.redhat.com
> > Subject: Re: gdb 5.3 bug
> >
> >
> > On Sat, Mar 01, 2003 at 06:59:45PM +0300, Lev Assinovsky wrote:
> > > Dear Daniel!
> > > Thank you very match for your advise!
> > > Snapshot gdb+dejagnu-20030228 works just fine!
> > > Thank a lot all guys who is involved in gdb development.
> > > I am sorry but I have to bother you with another gdb problem.
> > > The problem is I can't step into the function through the pointer
> > > if the function resides in dynamically loaded shared object
> > (library).
> > > Here is the simple test case:
> >
> > Hmm. Your testcase works on GNU/Linux, so it must be related to
> > i386-solaris shared library support. Maybe someone else on the list
> > can help.
> >
> > >
> > > 1. Shared object:
> > > ---------- cut here --------
> > > #include <iostream>
> > > using namespace std;
> > >
> > > extern "C" {
> > > void my_func()
> > > {
> > > cout << "This is my_func" << endl;
> > > }
> > >
> > > }
> > > ---------- cut here --------
> > > 2. Main:
> > > #include <iostream>
> > > #include <memory>
> > > #include <dlfcn.h>
> > > #include <link.h>
> > >
> > > using namespace std;
> > >
> > > void * handle;
> > >
> > > typedef void ( *Func_t)();
> > >
> > > Func_t getFunc()
> > > {
> > > Func_t p = (Func_t)dlsym ( handle, "my_func" );
> > > if ( NULL == p )
> > > {
> > > cout << dlerror() << endl;
> > > exit(2);
> > > }
> > > return p;
> > > }
> > >
> > > int main()
> > > {
> > > handle = (void*)
> > ::dlopen("./func_so/bin/i386-sun-solaris/func_so.so",
> > RTLD_NOW | RTLD_LOCAL | RTLD_GROUP);
> > > if (handle == NULL)
> > > {
> > > cout << dlerror() << endl;
> > > exit(2);
> > > }
> > >
> > > Func_t f = getFunc();
> > > f();
> > > }
> > > ---------- cut here --------
> > >
> > > This testcase works, but I can't step into f() (last line) in gdb.
> > > Is it possible to work around or fix this problem?
> > > Thanks in advance!
> > >
> > > ----
> > > Lev Assinovsky
> > > Aelita Software Corporation
> > > O&S Core Division, Programmer
> > > ICQ# 165072909
> > >
> > >
> > > > -----Original Message-----
> > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > Sent: Friday, February 28, 2003 8:19 PM
> > > > To: Lev Assinovsky; gdb@sources.redhat.com
> > > > Subject: Re: gdb 5.3 bug
> > > >
> > > >
> > > > On Thu, Feb 27, 2003 at 02:09:30PM -0500, Daniel Jacobowitz wrote:
> > > > > On Thu, Feb 27, 2003 at 09:11:14PM +0300, Lev Assinovsky wrote:
> > > > > > GNU gdb 5.3
> > > > > > Copyright 2002 Free Software Foundation, Inc.
> > > > > > GDB is free software, covered by the GNU General Public
> > > > License, and you are
> > > > > > welcome to change it and/or distribute copies of it under
> > > > certain conditions.
> > > > > > Type "show copying" to see the conditions.
> > > > > > There is absolutely no warranty for GDB. Type "show
> > > > warranty" for details.
> > > > > > This GDB was configured as "i386-pc-solaris2.8"...
> > > > > > (gdb) l
> > > > > >
> > > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > > 0x08136671 in finish_block (symbol=0x6e5f5f3a,
> > > > listhead=0x82241f4, old_blocks=0x3a787863, start=1634562671,
> > > > > > end=1634562720, objfile=0x8263fe0) at buildsym.c:304
> > > > > > 304 struct type *ftype = SYMBOL_TYPE (symbol);
> > > > > > (gdb)
> > > > > >
> > > > > >
> > > > > > Any clue what might be the reason of gdb crash?
> > > > >
> > > > > OK, the value of "symbol" is obviously wrong. Could you
> > > > privately send
> > > > > me the binary? If that's not possible, at least a
> > > > backtrace would be
> > > > > useful...
> > > >
> > > >
> > > > Lev,
> > > >
> > > > You're in luck, this has already been fixed. It appears to
> > > > be a bug in
> > > > the Sun compilers - it outputs end-of-function markers without a
> > > > corresponding beginning-of-function marker. If you get a
> > GDB snapshot
> > > > from CVS (http://sources.redhat.com/gdb/) it should handle
> > > > your program
> > > > gracefully.
> > > >
> > > > --
> > > > Daniel Jacobowitz
> > > > MontaVista Software Debian
> > GNU/Linux Developer
> > > >
> > >
> >
> > --
> > Daniel Jacobowitz
> > MontaVista Software Debian GNU/Linux Developer
> >
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: gdb 5.3 bug
@ 2003-03-05 14:27 Lev Assinovsky
2003-03-05 15:57 ` Daniel Jacobowitz
0 siblings, 1 reply; 19+ messages in thread
From: Lev Assinovsky @ 2003-03-05 14:27 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
Daniel!
I was wrong!
I can step into the function of dynamic library if
I run the command "sharedlibrary" before.
Why are symbols coming in only after that command
and auto-solib-add (=on) doesn't work?
----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909
> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Saturday, March 01, 2003 7:05 PM
> To: Lev Assinovsky
> Cc: gdb@sources.redhat.com
> Subject: Re: gdb 5.3 bug
>
>
> On Sat, Mar 01, 2003 at 06:59:45PM +0300, Lev Assinovsky wrote:
> > Dear Daniel!
> > Thank you very match for your advise!
> > Snapshot gdb+dejagnu-20030228 works just fine!
> > Thank a lot all guys who is involved in gdb development.
> > I am sorry but I have to bother you with another gdb problem.
> > The problem is I can't step into the function through the pointer
> > if the function resides in dynamically loaded shared object
> (library).
> > Here is the simple test case:
>
> Hmm. Your testcase works on GNU/Linux, so it must be related to
> i386-solaris shared library support. Maybe someone else on the list
> can help.
>
> >
> > 1. Shared object:
> > ---------- cut here --------
> > #include <iostream>
> > using namespace std;
> >
> > extern "C" {
> > void my_func()
> > {
> > cout << "This is my_func" << endl;
> > }
> >
> > }
> > ---------- cut here --------
> > 2. Main:
> > #include <iostream>
> > #include <memory>
> > #include <dlfcn.h>
> > #include <link.h>
> >
> > using namespace std;
> >
> > void * handle;
> >
> > typedef void ( *Func_t)();
> >
> > Func_t getFunc()
> > {
> > Func_t p = (Func_t)dlsym ( handle, "my_func" );
> > if ( NULL == p )
> > {
> > cout << dlerror() << endl;
> > exit(2);
> > }
> > return p;
> > }
> >
> > int main()
> > {
> > handle = (void*)
> ::dlopen("./func_so/bin/i386-sun-solaris/func_so.so",
> RTLD_NOW | RTLD_LOCAL | RTLD_GROUP);
> > if (handle == NULL)
> > {
> > cout << dlerror() << endl;
> > exit(2);
> > }
> >
> > Func_t f = getFunc();
> > f();
> > }
> > ---------- cut here --------
> >
> > This testcase works, but I can't step into f() (last line) in gdb.
> > Is it possible to work around or fix this problem?
> > Thanks in advance!
> >
> > ----
> > Lev Assinovsky
> > Aelita Software Corporation
> > O&S Core Division, Programmer
> > ICQ# 165072909
> >
> >
> > > -----Original Message-----
> > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > Sent: Friday, February 28, 2003 8:19 PM
> > > To: Lev Assinovsky; gdb@sources.redhat.com
> > > Subject: Re: gdb 5.3 bug
> > >
> > >
> > > On Thu, Feb 27, 2003 at 02:09:30PM -0500, Daniel Jacobowitz wrote:
> > > > On Thu, Feb 27, 2003 at 09:11:14PM +0300, Lev Assinovsky wrote:
> > > > > GNU gdb 5.3
> > > > > Copyright 2002 Free Software Foundation, Inc.
> > > > > GDB is free software, covered by the GNU General Public
> > > License, and you are
> > > > > welcome to change it and/or distribute copies of it under
> > > certain conditions.
> > > > > Type "show copying" to see the conditions.
> > > > > There is absolutely no warranty for GDB. Type "show
> > > warranty" for details.
> > > > > This GDB was configured as "i386-pc-solaris2.8"...
> > > > > (gdb) l
> > > > >
> > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > 0x08136671 in finish_block (symbol=0x6e5f5f3a,
> > > listhead=0x82241f4, old_blocks=0x3a787863, start=1634562671,
> > > > > end=1634562720, objfile=0x8263fe0) at buildsym.c:304
> > > > > 304 struct type *ftype = SYMBOL_TYPE (symbol);
> > > > > (gdb)
> > > > >
> > > > >
> > > > > Any clue what might be the reason of gdb crash?
> > > >
> > > > OK, the value of "symbol" is obviously wrong. Could you
> > > privately send
> > > > me the binary? If that's not possible, at least a
> > > backtrace would be
> > > > useful...
> > >
> > >
> > > Lev,
> > >
> > > You're in luck, this has already been fixed. It appears to
> > > be a bug in
> > > the Sun compilers - it outputs end-of-function markers without a
> > > corresponding beginning-of-function marker. If you get a
> GDB snapshot
> > > from CVS (http://sources.redhat.com/gdb/) it should handle
> > > your program
> > > gracefully.
> > >
> > > --
> > > Daniel Jacobowitz
> > > MontaVista Software Debian
> GNU/Linux Developer
> > >
> >
>
> --
> Daniel Jacobowitz
> MontaVista Software Debian GNU/Linux Developer
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: gdb 5.3 bug
@ 2003-03-01 17:40 Lev Assinovsky
0 siblings, 0 replies; 19+ messages in thread
From: Lev Assinovsky @ 2003-03-01 17:40 UTC (permalink / raw)
To: Lev Assinovsky, gdb; +Cc: Daniel Jacobowitz
[-- Attachment #1: Type: text/plain, Size: 5502 bytes --]
I just checked the same test case with the pair
SUNWspro/CC,SUNWspro/dbx - they work.
I can easily step into any function from
the dynamically loaded shared library :(
----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909
> -----Original Message-----
> From: Lev Assinovsky
> Sent: Saturday, March 01, 2003 7:14 PM
> To: gdb@sources.redhat.com
> Cc: Daniel Jacobowitz
> Subject: RE: gdb 5.3 bug
>
>
> Gdb guys! Help me with solaris please!!
>
> > Hmm. Your testcase works on GNU/Linux, so it must be related to
> > i386-solaris shared library support. Maybe someone else on the list
> > can help.
>
> ----
> Lev Assinovsky
> Aelita Software Corporation
> O&S Core Division, Programmer
> ICQ# 165072909
>
>
> > -----Original Message-----
> > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > Sent: Saturday, March 01, 2003 7:05 PM
> > To: Lev Assinovsky
> > Cc: gdb@sources.redhat.com
> > Subject: Re: gdb 5.3 bug
> >
> >
> > On Sat, Mar 01, 2003 at 06:59:45PM +0300, Lev Assinovsky wrote:
> > > Dear Daniel!
> > > Thank you very match for your advise!
> > > Snapshot gdb+dejagnu-20030228 works just fine!
> > > Thank a lot all guys who is involved in gdb development.
> > > I am sorry but I have to bother you with another gdb problem.
> > > The problem is I can't step into the function through the pointer
> > > if the function resides in dynamically loaded shared object
> > (library).
> > > Here is the simple test case:
> >
> > Hmm. Your testcase works on GNU/Linux, so it must be related to
> > i386-solaris shared library support. Maybe someone else on the list
> > can help.
> >
> > >
> > > 1. Shared object:
> > > ---------- cut here --------
> > > #include <iostream>
> > > using namespace std;
> > >
> > > extern "C" {
> > > void my_func()
> > > {
> > > cout << "This is my_func" << endl;
> > > }
> > >
> > > }
> > > ---------- cut here --------
> > > 2. Main:
> > > #include <iostream>
> > > #include <memory>
> > > #include <dlfcn.h>
> > > #include <link.h>
> > >
> > > using namespace std;
> > >
> > > void * handle;
> > >
> > > typedef void ( *Func_t)();
> > >
> > > Func_t getFunc()
> > > {
> > > Func_t p = (Func_t)dlsym ( handle, "my_func" );
> > > if ( NULL == p )
> > > {
> > > cout << dlerror() << endl;
> > > exit(2);
> > > }
> > > return p;
> > > }
> > >
> > > int main()
> > > {
> > > handle = (void*)
> > ::dlopen("./func_so/bin/i386-sun-solaris/func_so.so",
> > RTLD_NOW | RTLD_LOCAL | RTLD_GROUP);
> > > if (handle == NULL)
> > > {
> > > cout << dlerror() << endl;
> > > exit(2);
> > > }
> > >
> > > Func_t f = getFunc();
> > > f();
> > > }
> > > ---------- cut here --------
> > >
> > > This testcase works, but I can't step into f() (last line) in gdb.
> > > Is it possible to work around or fix this problem?
> > > Thanks in advance!
> > >
> > > ----
> > > Lev Assinovsky
> > > Aelita Software Corporation
> > > O&S Core Division, Programmer
> > > ICQ# 165072909
> > >
> > >
> > > > -----Original Message-----
> > > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > > Sent: Friday, February 28, 2003 8:19 PM
> > > > To: Lev Assinovsky; gdb@sources.redhat.com
> > > > Subject: Re: gdb 5.3 bug
> > > >
> > > >
> > > > On Thu, Feb 27, 2003 at 02:09:30PM -0500, Daniel
> Jacobowitz wrote:
> > > > > On Thu, Feb 27, 2003 at 09:11:14PM +0300, Lev
> Assinovsky wrote:
> > > > > > GNU gdb 5.3
> > > > > > Copyright 2002 Free Software Foundation, Inc.
> > > > > > GDB is free software, covered by the GNU General Public
> > > > License, and you are
> > > > > > welcome to change it and/or distribute copies of it under
> > > > certain conditions.
> > > > > > Type "show copying" to see the conditions.
> > > > > > There is absolutely no warranty for GDB. Type "show
> > > > warranty" for details.
> > > > > > This GDB was configured as "i386-pc-solaris2.8"...
> > > > > > (gdb) l
> > > > > >
> > > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > > 0x08136671 in finish_block (symbol=0x6e5f5f3a,
> > > > listhead=0x82241f4, old_blocks=0x3a787863, start=1634562671,
> > > > > > end=1634562720, objfile=0x8263fe0) at buildsym.c:304
> > > > > > 304 struct type *ftype = SYMBOL_TYPE (symbol);
> > > > > > (gdb)
> > > > > >
> > > > > >
> > > > > > Any clue what might be the reason of gdb crash?
> > > > >
> > > > > OK, the value of "symbol" is obviously wrong. Could you
> > > > privately send
> > > > > me the binary? If that's not possible, at least a
> > > > backtrace would be
> > > > > useful...
> > > >
> > > >
> > > > Lev,
> > > >
> > > > You're in luck, this has already been fixed. It appears to
> > > > be a bug in
> > > > the Sun compilers - it outputs end-of-function markers without a
> > > > corresponding beginning-of-function marker. If you get a
> > GDB snapshot
> > > > from CVS (http://sources.redhat.com/gdb/) it should handle
> > > > your program
> > > > gracefully.
> > > >
> > > > --
> > > > Daniel Jacobowitz
> > > > MontaVista Software Debian
> > GNU/Linux Developer
> > > >
> > >
> >
> > --
> > Daniel Jacobowitz
> > MontaVista Software Debian
> GNU/Linux Developer
> >
>
[-- Attachment #2: load.cpp --]
[-- Type: application/octet-stream, Size: 575 bytes --]
#include <iostream>
#include <memory>
#include <dlfcn.h>
#include <link.h>
using namespace std;
void * handle;
typedef void ( *Func_t)();
Func_t getFunc()
{
Func_t p = (Func_t)dlsym ( handle, "my_func" );
if ( NULL == p )
{
cout << dlerror() << endl;
exit(2);
}
return p;
}
int main()
{
handle = (void*) ::dlopen("./func_so/bin/i386-sun-solaris/func_so.so", RTLD_NOW | RTLD_LOCAL | RTLD_GROUP);
if (handle == NULL)
{
cout << dlerror() << endl;
exit(2);
}
Func_t f = getFunc();
f();
}
[-- Attachment #3: func.cpp --]
[-- Type: application/octet-stream, Size: 132 bytes --]
#include <iostream>
using namespace std;
extern "C" {
void my_func()
{
cout << "This is my_func" << endl;
}
}
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: gdb 5.3 bug
@ 2003-03-01 16:13 Lev Assinovsky
0 siblings, 0 replies; 19+ messages in thread
From: Lev Assinovsky @ 2003-03-01 16:13 UTC (permalink / raw)
To: gdb; +Cc: Daniel Jacobowitz
Gdb guys! Help me with solaris please!!
> Hmm. Your testcase works on GNU/Linux, so it must be related to
> i386-solaris shared library support. Maybe someone else on the list
> can help.
----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909
> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Saturday, March 01, 2003 7:05 PM
> To: Lev Assinovsky
> Cc: gdb@sources.redhat.com
> Subject: Re: gdb 5.3 bug
>
>
> On Sat, Mar 01, 2003 at 06:59:45PM +0300, Lev Assinovsky wrote:
> > Dear Daniel!
> > Thank you very match for your advise!
> > Snapshot gdb+dejagnu-20030228 works just fine!
> > Thank a lot all guys who is involved in gdb development.
> > I am sorry but I have to bother you with another gdb problem.
> > The problem is I can't step into the function through the pointer
> > if the function resides in dynamically loaded shared object
> (library).
> > Here is the simple test case:
>
> Hmm. Your testcase works on GNU/Linux, so it must be related to
> i386-solaris shared library support. Maybe someone else on the list
> can help.
>
> >
> > 1. Shared object:
> > ---------- cut here --------
> > #include <iostream>
> > using namespace std;
> >
> > extern "C" {
> > void my_func()
> > {
> > cout << "This is my_func" << endl;
> > }
> >
> > }
> > ---------- cut here --------
> > 2. Main:
> > #include <iostream>
> > #include <memory>
> > #include <dlfcn.h>
> > #include <link.h>
> >
> > using namespace std;
> >
> > void * handle;
> >
> > typedef void ( *Func_t)();
> >
> > Func_t getFunc()
> > {
> > Func_t p = (Func_t)dlsym ( handle, "my_func" );
> > if ( NULL == p )
> > {
> > cout << dlerror() << endl;
> > exit(2);
> > }
> > return p;
> > }
> >
> > int main()
> > {
> > handle = (void*)
> ::dlopen("./func_so/bin/i386-sun-solaris/func_so.so",
> RTLD_NOW | RTLD_LOCAL | RTLD_GROUP);
> > if (handle == NULL)
> > {
> > cout << dlerror() << endl;
> > exit(2);
> > }
> >
> > Func_t f = getFunc();
> > f();
> > }
> > ---------- cut here --------
> >
> > This testcase works, but I can't step into f() (last line) in gdb.
> > Is it possible to work around or fix this problem?
> > Thanks in advance!
> >
> > ----
> > Lev Assinovsky
> > Aelita Software Corporation
> > O&S Core Division, Programmer
> > ICQ# 165072909
> >
> >
> > > -----Original Message-----
> > > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > > Sent: Friday, February 28, 2003 8:19 PM
> > > To: Lev Assinovsky; gdb@sources.redhat.com
> > > Subject: Re: gdb 5.3 bug
> > >
> > >
> > > On Thu, Feb 27, 2003 at 02:09:30PM -0500, Daniel Jacobowitz wrote:
> > > > On Thu, Feb 27, 2003 at 09:11:14PM +0300, Lev Assinovsky wrote:
> > > > > GNU gdb 5.3
> > > > > Copyright 2002 Free Software Foundation, Inc.
> > > > > GDB is free software, covered by the GNU General Public
> > > License, and you are
> > > > > welcome to change it and/or distribute copies of it under
> > > certain conditions.
> > > > > Type "show copying" to see the conditions.
> > > > > There is absolutely no warranty for GDB. Type "show
> > > warranty" for details.
> > > > > This GDB was configured as "i386-pc-solaris2.8"...
> > > > > (gdb) l
> > > > >
> > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > 0x08136671 in finish_block (symbol=0x6e5f5f3a,
> > > listhead=0x82241f4, old_blocks=0x3a787863, start=1634562671,
> > > > > end=1634562720, objfile=0x8263fe0) at buildsym.c:304
> > > > > 304 struct type *ftype = SYMBOL_TYPE (symbol);
> > > > > (gdb)
> > > > >
> > > > >
> > > > > Any clue what might be the reason of gdb crash?
> > > >
> > > > OK, the value of "symbol" is obviously wrong. Could you
> > > privately send
> > > > me the binary? If that's not possible, at least a
> > > backtrace would be
> > > > useful...
> > >
> > >
> > > Lev,
> > >
> > > You're in luck, this has already been fixed. It appears to
> > > be a bug in
> > > the Sun compilers - it outputs end-of-function markers without a
> > > corresponding beginning-of-function marker. If you get a
> GDB snapshot
> > > from CVS (http://sources.redhat.com/gdb/) it should handle
> > > your program
> > > gracefully.
> > >
> > > --
> > > Daniel Jacobowitz
> > > MontaVista Software Debian
> GNU/Linux Developer
> > >
> >
>
> --
> Daniel Jacobowitz
> MontaVista Software Debian GNU/Linux Developer
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 5.3 bug
2003-03-01 15:59 Lev Assinovsky
@ 2003-03-01 16:05 ` Daniel Jacobowitz
0 siblings, 0 replies; 19+ messages in thread
From: Daniel Jacobowitz @ 2003-03-01 16:05 UTC (permalink / raw)
To: Lev Assinovsky; +Cc: gdb
On Sat, Mar 01, 2003 at 06:59:45PM +0300, Lev Assinovsky wrote:
> Dear Daniel!
> Thank you very match for your advise!
> Snapshot gdb+dejagnu-20030228 works just fine!
> Thank a lot all guys who is involved in gdb development.
> I am sorry but I have to bother you with another gdb problem.
> The problem is I can't step into the function through the pointer
> if the function resides in dynamically loaded shared object (library).
> Here is the simple test case:
Hmm. Your testcase works on GNU/Linux, so it must be related to
i386-solaris shared library support. Maybe someone else on the list
can help.
>
> 1. Shared object:
> ---------- cut here --------
> #include <iostream>
> using namespace std;
>
> extern "C" {
> void my_func()
> {
> cout << "This is my_func" << endl;
> }
>
> }
> ---------- cut here --------
> 2. Main:
> #include <iostream>
> #include <memory>
> #include <dlfcn.h>
> #include <link.h>
>
> using namespace std;
>
> void * handle;
>
> typedef void ( *Func_t)();
>
> Func_t getFunc()
> {
> Func_t p = (Func_t)dlsym ( handle, "my_func" );
> if ( NULL == p )
> {
> cout << dlerror() << endl;
> exit(2);
> }
> return p;
> }
>
> int main()
> {
> handle = (void*) ::dlopen("./func_so/bin/i386-sun-solaris/func_so.so", RTLD_NOW | RTLD_LOCAL | RTLD_GROUP);
> if (handle == NULL)
> {
> cout << dlerror() << endl;
> exit(2);
> }
>
> Func_t f = getFunc();
> f();
> }
> ---------- cut here --------
>
> This testcase works, but I can't step into f() (last line) in gdb.
> Is it possible to work around or fix this problem?
> Thanks in advance!
>
> ----
> Lev Assinovsky
> Aelita Software Corporation
> O&S Core Division, Programmer
> ICQ# 165072909
>
>
> > -----Original Message-----
> > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > Sent: Friday, February 28, 2003 8:19 PM
> > To: Lev Assinovsky; gdb@sources.redhat.com
> > Subject: Re: gdb 5.3 bug
> >
> >
> > On Thu, Feb 27, 2003 at 02:09:30PM -0500, Daniel Jacobowitz wrote:
> > > On Thu, Feb 27, 2003 at 09:11:14PM +0300, Lev Assinovsky wrote:
> > > > GNU gdb 5.3
> > > > Copyright 2002 Free Software Foundation, Inc.
> > > > GDB is free software, covered by the GNU General Public
> > License, and you are
> > > > welcome to change it and/or distribute copies of it under
> > certain conditions.
> > > > Type "show copying" to see the conditions.
> > > > There is absolutely no warranty for GDB. Type "show
> > warranty" for details.
> > > > This GDB was configured as "i386-pc-solaris2.8"...
> > > > (gdb) l
> > > >
> > > > Program received signal SIGSEGV, Segmentation fault.
> > > > 0x08136671 in finish_block (symbol=0x6e5f5f3a,
> > listhead=0x82241f4, old_blocks=0x3a787863, start=1634562671,
> > > > end=1634562720, objfile=0x8263fe0) at buildsym.c:304
> > > > 304 struct type *ftype = SYMBOL_TYPE (symbol);
> > > > (gdb)
> > > >
> > > >
> > > > Any clue what might be the reason of gdb crash?
> > >
> > > OK, the value of "symbol" is obviously wrong. Could you
> > privately send
> > > me the binary? If that's not possible, at least a
> > backtrace would be
> > > useful...
> >
> >
> > Lev,
> >
> > You're in luck, this has already been fixed. It appears to
> > be a bug in
> > the Sun compilers - it outputs end-of-function markers without a
> > corresponding beginning-of-function marker. If you get a GDB snapshot
> > from CVS (http://sources.redhat.com/gdb/) it should handle
> > your program
> > gracefully.
> >
> > --
> > Daniel Jacobowitz
> > MontaVista Software Debian GNU/Linux Developer
> >
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: gdb 5.3 bug
@ 2003-03-01 15:59 Lev Assinovsky
2003-03-01 16:05 ` Daniel Jacobowitz
0 siblings, 1 reply; 19+ messages in thread
From: Lev Assinovsky @ 2003-03-01 15:59 UTC (permalink / raw)
To: Daniel Jacobowitz, gdb
Dear Daniel!
Thank you very match for your advise!
Snapshot gdb+dejagnu-20030228 works just fine!
Thank a lot all guys who is involved in gdb development.
I am sorry but I have to bother you with another gdb problem.
The problem is I can't step into the function through the pointer
if the function resides in dynamically loaded shared object (library).
Here is the simple test case:
1. Shared object:
---------- cut here --------
#include <iostream>
using namespace std;
extern "C" {
void my_func()
{
cout << "This is my_func" << endl;
}
}
---------- cut here --------
2. Main:
#include <iostream>
#include <memory>
#include <dlfcn.h>
#include <link.h>
using namespace std;
void * handle;
typedef void ( *Func_t)();
Func_t getFunc()
{
Func_t p = (Func_t)dlsym ( handle, "my_func" );
if ( NULL == p )
{
cout << dlerror() << endl;
exit(2);
}
return p;
}
int main()
{
handle = (void*) ::dlopen("./func_so/bin/i386-sun-solaris/func_so.so", RTLD_NOW | RTLD_LOCAL | RTLD_GROUP);
if (handle == NULL)
{
cout << dlerror() << endl;
exit(2);
}
Func_t f = getFunc();
f();
}
---------- cut here --------
This testcase works, but I can't step into f() (last line) in gdb.
Is it possible to work around or fix this problem?
Thanks in advance!
----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909
> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Friday, February 28, 2003 8:19 PM
> To: Lev Assinovsky; gdb@sources.redhat.com
> Subject: Re: gdb 5.3 bug
>
>
> On Thu, Feb 27, 2003 at 02:09:30PM -0500, Daniel Jacobowitz wrote:
> > On Thu, Feb 27, 2003 at 09:11:14PM +0300, Lev Assinovsky wrote:
> > > GNU gdb 5.3
> > > Copyright 2002 Free Software Foundation, Inc.
> > > GDB is free software, covered by the GNU General Public
> License, and you are
> > > welcome to change it and/or distribute copies of it under
> certain conditions.
> > > Type "show copying" to see the conditions.
> > > There is absolutely no warranty for GDB. Type "show
> warranty" for details.
> > > This GDB was configured as "i386-pc-solaris2.8"...
> > > (gdb) l
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x08136671 in finish_block (symbol=0x6e5f5f3a,
> listhead=0x82241f4, old_blocks=0x3a787863, start=1634562671,
> > > end=1634562720, objfile=0x8263fe0) at buildsym.c:304
> > > 304 struct type *ftype = SYMBOL_TYPE (symbol);
> > > (gdb)
> > >
> > >
> > > Any clue what might be the reason of gdb crash?
> >
> > OK, the value of "symbol" is obviously wrong. Could you
> privately send
> > me the binary? If that's not possible, at least a
> backtrace would be
> > useful...
>
>
> Lev,
>
> You're in luck, this has already been fixed. It appears to
> be a bug in
> the Sun compilers - it outputs end-of-function markers without a
> corresponding beginning-of-function marker. If you get a GDB snapshot
> from CVS (http://sources.redhat.com/gdb/) it should handle
> your program
> gracefully.
>
> --
> Daniel Jacobowitz
> MontaVista Software Debian GNU/Linux Developer
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 5.3 bug
2003-02-27 19:09 ` Daniel Jacobowitz
@ 2003-02-28 17:18 ` Daniel Jacobowitz
0 siblings, 0 replies; 19+ messages in thread
From: Daniel Jacobowitz @ 2003-02-28 17:18 UTC (permalink / raw)
To: Lev Assinovsky, gdb
On Thu, Feb 27, 2003 at 02:09:30PM -0500, Daniel Jacobowitz wrote:
> On Thu, Feb 27, 2003 at 09:11:14PM +0300, Lev Assinovsky wrote:
> > GNU gdb 5.3
> > Copyright 2002 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB. Type "show warranty" for details.
> > This GDB was configured as "i386-pc-solaris2.8"...
> > (gdb) l
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x08136671 in finish_block (symbol=0x6e5f5f3a, listhead=0x82241f4, old_blocks=0x3a787863, start=1634562671,
> > end=1634562720, objfile=0x8263fe0) at buildsym.c:304
> > 304 struct type *ftype = SYMBOL_TYPE (symbol);
> > (gdb)
> >
> >
> > Any clue what might be the reason of gdb crash?
>
> OK, the value of "symbol" is obviously wrong. Could you privately send
> me the binary? If that's not possible, at least a backtrace would be
> useful...
Lev,
You're in luck, this has already been fixed. It appears to be a bug in
the Sun compilers - it outputs end-of-function markers without a
corresponding beginning-of-function marker. If you get a GDB snapshot
from CVS (http://sources.redhat.com/gdb/) it should handle your program
gracefully.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 5.3 bug
2003-02-27 18:11 Lev Assinovsky
@ 2003-02-27 19:09 ` Daniel Jacobowitz
2003-02-28 17:18 ` Daniel Jacobowitz
0 siblings, 1 reply; 19+ messages in thread
From: Daniel Jacobowitz @ 2003-02-27 19:09 UTC (permalink / raw)
To: Lev Assinovsky; +Cc: gdb
On Thu, Feb 27, 2003 at 09:11:14PM +0300, Lev Assinovsky wrote:
> GNU gdb 5.3
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-pc-solaris2.8"...
> (gdb) l
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x08136671 in finish_block (symbol=0x6e5f5f3a, listhead=0x82241f4, old_blocks=0x3a787863, start=1634562671,
> end=1634562720, objfile=0x8263fe0) at buildsym.c:304
> 304 struct type *ftype = SYMBOL_TYPE (symbol);
> (gdb)
>
>
> Any clue what might be the reason of gdb crash?
OK, the value of "symbol" is obviously wrong. Could you privately send
me the binary? If that's not possible, at least a backtrace would be
useful...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 19+ messages in thread
* gdb 5.3 bug
@ 2003-02-27 18:11 Lev Assinovsky
2003-02-27 19:09 ` Daniel Jacobowitz
0 siblings, 1 reply; 19+ messages in thread
From: Lev Assinovsky @ 2003-02-27 18:11 UTC (permalink / raw)
To: gdb
Hi All!
I have executable "client" complied by gcc 3.2 (with gnu as and gnu ld)
I use gdb 5.3 for debugging and get it's crash for very simple case:
lev@dog comm_test$ gdb bin/i386-sun-solaris/debug/client
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.8"...
(gdb) l
Segmentation Fault (core dumped)
lev@dog comm_test$
Then I started to debug gdb:
lev@dog comm_test$ gdb /usr/local/bin/gdb
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.8"...
(gdb) r bin/i386-sun-solaris/debug/client
Starting program: /export/home/local/bin/gdb bin/i386-sun-solaris/debug/client
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.8"...
(gdb) l
Program received signal SIGSEGV, Segmentation fault.
0x08136671 in finish_block (symbol=0x6e5f5f3a, listhead=0x82241f4, old_blocks=0x3a787863, start=1634562671,
end=1634562720, objfile=0x8263fe0) at buildsym.c:304
304 struct type *ftype = SYMBOL_TYPE (symbol);
(gdb)
Any clue what might be the reason of gdb crash?
Thank you!
(gdb 5.2 has been crashed also)
----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2003-03-07 14:35 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-05 16:54 gdb 5.3 bug Lev Assinovsky
-- strict thread matches above, loose matches on Subject: below --
2003-03-07 14:35 Lev Assinovsky
2003-03-07 11:05 Lev Assinovsky
2003-03-07 14:26 ` Daniel Jacobowitz
2003-03-05 17:32 Lev Assinovsky
2003-03-05 17:52 ` Kevin Buettner
2003-03-05 17:12 Lev Assinovsky
2003-03-05 17:23 ` Daniel Jacobowitz
2003-03-05 16:06 Lev Assinovsky
2003-03-05 16:12 ` Daniel Jacobowitz
2003-03-05 14:27 Lev Assinovsky
2003-03-05 15:57 ` Daniel Jacobowitz
2003-03-01 17:40 Lev Assinovsky
2003-03-01 16:13 Lev Assinovsky
2003-03-01 15:59 Lev Assinovsky
2003-03-01 16:05 ` Daniel Jacobowitz
2003-02-27 18:11 Lev Assinovsky
2003-02-27 19:09 ` Daniel Jacobowitz
2003-02-28 17:18 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).