All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: Phil Blundell <pb@pbcl.net>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/2 RFC] rpm: Add workaround for debugedit-segv
Date: Mon, 25 Mar 2013 14:32:25 -0500	[thread overview]
Message-ID: <5150A649.8090409@windriver.com> (raw)
In-Reply-To: <1364233524.25692.139.camel@phil-desktop.brightsign>

On 3/25/13 12:45 PM, Phil Blundell wrote:
> On Mon, 2013-03-25 at 12:10 -0500, Mark Hatle wrote:
>> I'm going to look into identifying if the section is a NOBITS and skipping the
>> whole operation if it is.
>
> That would mean that a change in the size of the .bss wouldn't have any
> impact on the hash.  Maybe that's fine for your application though, I
> dunno.

I'm not completely familiar with how the buildid is calculated, other then an 
md5 hash over the sections themselves.  I can't think of a case where the 
contents of the sections wouldn't change along with the .bss and .plt size.

(buildid is supposed to be used by gdb to find/verify that the debuginfo matches 
the binary actually being debugged...)

Through my google search, I never found a full spec of what the buildid was 
supposed to contain, only a high-level description from an old Fedora 8 work 
item.  (Note, as long the buildid is consistent it really doesn't appear to 
matter how it was generated, just that both the app and debuginfo contain it.)

--Mark


> p.
>
>




  reply	other threads:[~2013-03-25 19:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-25 17:19 [PATCH 0/2 RFC] workaround for debugedit segv Mark Hatle
2013-03-25 17:19 ` [PATCH 1/2 RFC] rpm: Add workaround for debugedit-segv Mark Hatle
2013-03-25 17:02   ` Phil Blundell
2013-03-25 17:10     ` Mark Hatle
2013-03-25 17:45       ` Phil Blundell
2013-03-25 19:32         ` Mark Hatle [this message]
2013-03-25 21:47           ` Mark Hatle
2013-03-26 10:38             ` Phil Blundell
2013-03-26 12:20               ` Mark Hatle
2013-03-25 17:19 ` [PATCH 2/2 RFC] package.bbclass: Trigger a bb.error if split/strip fails Mark Hatle
2013-03-25 17:47 ` [PATCH 0/2 RFC] workaround for debugedit segv Richard Purdie

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=5150A649.8090409@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=pb@pbcl.net \
    /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.