All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <yocto@yoctoproject.org>
Subject: Re: sysroot for use with GDB
Date: Wed, 5 Dec 2012 13:32:13 -0600	[thread overview]
Message-ID: <50BFA13D.8020609@windriver.com> (raw)
In-Reply-To: <20121205123818.C17EB200FF2@gemini.denx.de>

On 12/5/12 6:38 AM, Wolfgang Denk wrote:
> Hello,
>
> nobody here who could help out?
>
> In message <20121203124234.6327B200FF8@gemini.denx.de> I wrote:
>>
>> according to the documentation [1] the right way to debug applications
>> on the target is to load the target library information in GDB using
>>
>> 	set solib-absolute-prefix /path/to/tmp/rootfs
>>
>> i. e. referring it to the libraries in the target root file system
>> image.  Assuming the target root file system uses by defualt stripped
>> libraries, we need to set up a copy of the rootfs with debug
>> information included.
>>
>> But do we really have to?  Why cannot we use the libraries present in
>> the SDK's sysroot directory (i. e. what OECORE_TARGET_SYSROOT points
>> to) ?
>
> It appears that documentation and code are inconsistent; at least the
> eclipse plugin generates a .gdbinit script which contains a
>
> 	set sysroot /opt/poky/1.3/sysroots/armv7a-vfp-neon-poky-linux-gnueabi
>
> statement, i. e. it uses OECORE_TARGET_SYSROOT as I thought should
> work - but it doesn't.
>
>> Trying to do so, we see that it fails.  Our current suspicion is that
>> maybe prelinking of the target images and libraries introduces some
>> incompatibility.  Is this a reasonable assumption, and if so, is this
>> a problem that should be fixed, or unavoidable for some reason?  Or is
>> there a problem with the libraries in OECORE_TARGET_SYSROOT ?

Prelinking should not cause a problem.  GDB knows how to translate the debuginfo 
addresses to the end runtime addresses.

The only thing I've seen in the past that has caused a problem is when the dbg 
stuff was not installed into the sysroot.  GDB will fall back into loading the 
binaries from the sysroot, which will not contain the debug info causing problems.

It's best if you can set the sysroot to the same filesystem as being executed, 
but if you can't this is reasonable.

>> All help welcome - thanks in advance.
>>
>> [1] http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#platdev-gdb-remotedebug-launch-gdb
>
> OK, guess I should enter a bug in bugzilla, then?


>
> Best regards,
>
> Wolfgang Denk
>



      parent reply	other threads:[~2012-12-05 19:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-03 12:42 sysroot for use with GDB Wolfgang Denk
2012-12-05 12:38 ` Wolfgang Denk
2012-12-05 13:14   ` Wolfgang Denk
2012-12-05 19:32   ` Mark Hatle [this message]

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=50BFA13D.8020609@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=yocto@yoctoproject.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.