Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Raphael Zulliger <zulliger@indel.ch>
To: Aleksandar Ristovski <aristovski@qnx.com>
Cc: gdb@sourceware.org
Subject: Re: Ensure correct symbol-file when attaching to a (remote) process
Date: Tue, 29 Jan 2013 03:18:00 -0000	[thread overview]
Message-ID: <51073F6D.3030806@indel.ch> (raw)
In-Reply-To: <50D4D099.3030601@qnx.com>

(I apologize: I've replied to this mail some weeks ago - but forgot to 
CC to the list. I therefore resend this email)

On 12/21/2012 10:11 PM, Aleksandar Ristovski wrote:
> Interesting timing. I have just posted 
> http://sourceware.org/ml/gdb-patches/2012-12/msg00776.html addressing 
> this issue.
Indeed . Thanks!
>
> The check is not exhaustive, but for most practical purposes it should 
> suffice. It verifies that in-memory elf header and pheaders match 
> those found in the bfd.
>
> Of course it will not detect difference in all cases, e.g. very small 
> changes that do not affect loadable segment size. Example:
>
> - static int foo;
> - static int bar;
> + static int bar;
> + static int foo;
>
> Still, it should be much better than no check at all.
I'm not very familiar with ELF header information... But after to some 
quick investigation, it seems that this mechanism "only" helps to detect 
changes that affect "changes in size" or "changes of address", right?

Moreover, if I understood it correctly, we'd have a fundamental problem 
using this mechanism in our scenario: We don't download the ELF file to 
the embedded system. Instead, we process the ELF file with objcopy 
(-Osrec) on the developer system and only download the produced SREC 
file - which contains no ELF header information anymore.


      parent reply	other threads:[~2013-01-29  3:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-21  6:05 Raphael Zulliger
2012-12-21 16:11 ` Jan Kratochvil
2012-12-21 18:17   ` John Gilmore
2013-01-02 17:57     ` Pedro Alves
2013-01-12 10:59       ` Martin Runge
     [not found]       ` <50EA78FB.3040609@indel.ch>
2013-01-14 18:57         ` Pedro Alves
2013-01-29  3:18       ` Raphael Zulliger
2013-01-29  3:51         ` Raphael Zulliger
2013-02-06 18:47           ` Tom Tromey
2012-12-21 21:12   ` Aleksandar Ristovski
2012-12-22  0:38     ` John Gilmore
2012-12-22  2:54       ` Aleksandar Ristovski
2012-12-24 20:02         ` Aleksandar Ristovski
2012-12-26  0:47           ` John Gilmore
2012-12-27 20:13             ` Aleksandar Ristovski
2013-01-29  3:18     ` Raphael Zulliger [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=51073F6D.3030806@indel.ch \
    --to=zulliger@indel.ch \
    --cc=aristovski@qnx.com \
    --cc=gdb@sourceware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox