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
>
next 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