From: "Kevin \"Squail\" Endres" <kevine@wildseed.com>
To: 'Kevin Buettner' <kevinb@redhat.com>
Cc: "'gdb@sources.redhat.com'" <gdb@sources.redhat.com>
Subject: RE: arm gdbserver and shared object function resolution
Date: Mon, 29 Apr 2002 17:59:00 -0000 [thread overview]
Message-ID: <43CB1396676FD4119F03001083FD2994F5F17E@neptune.kirkland.local> (raw)
my symbols are loading correctly.
What I need to do: Break into the debugger inside a shared object either
remotely or locally - platform is arm.
using 5.2 (the current snapshot was a little flaky..) I am seeing the
following behavior
(Note: arm target)
native arm gdb:
run gdb targeted at app, set break at main - run - set break at function
inside shared object - run
RESULT: gdb dies (out of memory)
run app - run gdb targeted at app - attach to pid - set break at function
inside shared object
RESULT: gdb dies (out of memory)
cross-targeted:
run target - run cross (read in symbol file) - set break - continue - i get
the error below.
Tho i am sure i am doing something incorrectly it appears:
1) Arm Cross target remote debugging does not support breaks in shared
libraries as of the current snapshot
2) there is a bug in the current native arm gdb that prevents setting a
breakpoint in a shared library and tripping the breakpoint (without running
out of memory)
Any help is greatly appreciated.
:]k
-----Original Message-----
From: Kevin Buettner [mailto:kevinb@redhat.com]
Sent: Monday, April 29, 2002 5:14 PM
To: Kevin "Squail" Endres; gdb@sources.redhat.com
Subject: Re: arm gdbserver and shared object function resolution
On Apr 29, 4:34pm, Kevin \Squail\ Endres wrote:
> note: I can now load the symbols from the file on the host (and thus
resolve
> the function to an address and set a breakpoint). However - if i target
the
> remote target after setting the breakpoint i get the following error:
>
> warning: shared library handler failed to enable breakpoint. is the issue
> with the current cross target gdb or is it with gdbserver?
It is critical that GDB be able to find your target's dynamic linker
and load its symbols. To do this, you normally use
``set solib-absolute-prefix'' to tell gdb where to find the sys-root
for the target's libraries. If you're not doing this, then perhaps
that's your problem?
It is also important for the libraries in the sys-root location on
the host to be exactly the same as those found on the target. All
kinds of strange things can happen if this is not the case.
Kevin
next reply other threads:[~2002-04-30 0:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-29 17:59 Kevin "Squail" Endres [this message]
2002-04-30 8:01 ` Daniel Jacobowitz
-- strict thread matches above, loose matches on Subject: below --
2002-05-06 9:33 Kevin "Squail" Endres
2002-04-30 16:31 Kevin "Squail" Endres
2002-04-29 16:34 Kevin "Squail" Endres
2002-04-29 17:14 ` Kevin Buettner
2002-04-29 16:11 Kevin "Squail" Endres
2002-04-29 15:20 Kevin "Squail" Endres
2002-04-29 15:08 Kevin "Squail" Endres
2002-04-29 15:19 ` Daniel Jacobowitz
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=43CB1396676FD4119F03001083FD2994F5F17E@neptune.kirkland.local \
--to=kevine@wildseed.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