Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Lev Assinovsky" <LAssinovsky@algorithm.aelita.com>
To: "Kevin Buettner" <kevinb@redhat.com>, <gdb@sources.redhat.com>
Subject: RE: gdb + dynamic libs problem
Date: Thu, 20 Feb 2003 10:25:00 -0000	[thread overview]
Message-ID: <3F6F4712B759A34ABD453A8B39C10D6226694D@bagman.edm.com> (raw)

Thanks Kevin!
My response see below.
I was so happy if anybody could help me!

----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909


> -----Original Message-----
> From: Kevin Buettner [mailto:kevinb@redhat.com]
> Sent: Thursday, February 20, 2003 12:42 AM
> To: Lev Assinovsky; gdb@sources.redhat.com
> Subject: Re: gdb + dynamic libs problem
> 
> 
> On Feb 18,  2:08pm, Lev Assinovsky wrote:
> 
> > I try to debug the application where dynamic objects 
> > are loaded through user's dlopen explicit call.
> > The only way to set breakpoint in .so is to open source after 
> > .so got loaded (I have to detect this moment myself).
> 
> GDB can help you with this if you you do ``set 
> stop-on-solib-events 1''.
> You'll probably want to do this well after your program has started
> though to avoid stopping every time one of the shared 
> libraries specified
> on the link line gets loaded.
> 
> > I perform source opening by issue the commands "shared library" and
> > "list <file>:1".
> 
> Have you disabled ``auto-solib-add''?  If not, you shouldn't need to
> invoke the ``sharedlibrary'' command directly.  I.e, gdb should
> automatically load the shared libraries for you (unless you've told it
> not to).

Here the point is! I don't have "classic" shared libraries like 
libxxx.so. And application is not linked with them.
I have xxx.so and load it via dlopen function. I.e. gdb doesn't have
any knowledge about c++ files in my shared object until I type in "sharedlibrary" command!

> 
> > But if the source file is big gdb get crash.
> > It there any way to increase gdb resources to consume 
> > larger files (symbol tables?)
> 
> Which platform are you running on?  On most platforms, gdb should
> be able to use whatever resources the operating system is able to
> give it.  Thus, you may need to play around with ulimit, adjusting
> the amount of memory, swap space, etc.

I tried solaris8-intel and solaris8-sparc platforms with ulimit=unlimited.

> 
> Kevin
> 


             reply	other threads:[~2003-02-20 10:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-20 10:25 Lev Assinovsky [this message]
2003-02-20 14:59 ` Daniel Jacobowitz
2003-02-20 15:27 ` Kevin Buettner
  -- strict thread matches above, loose matches on Subject: below --
2003-02-18 11:08 Lev Assinovsky
2003-02-19 21:42 ` Kevin Buettner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F6F4712B759A34ABD453A8B39C10D6226694D@bagman.edm.com \
    --to=lassinovsky@algorithm.aelita.com \
    --cc=gdb@sources.redhat.com \
    --cc=kevinb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox