Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Thiago Jung Bauermann <bauerman@br.ibm.com>
Cc: gdb-patches ml <gdb-patches@sourceware.org>
Subject: Re: [RFA] Document lm_addr_check.
Date: Mon, 04 Jul 2011 20:34:00 -0000	[thread overview]
Message-ID: <20110704201605.GA9482@host1.jankratochvil.net> (raw)
In-Reply-To: <1309808956.4471.16.camel@hactar>

Hi Thiago,

On Mon, 04 Jul 2011 21:49:16 +0200, Thiago Jung Bauermann wrote:
>  static CORE_ADDR
>  lm_addr_check (struct so_list *so, bfd *abfd)
->
> +/* Returns the load address of the given shared object.

It returns lm_info->l_addr where is the comment:
    /* Amount by which addresses in the binary should be relocated to
       match the inferior.  This could most often be taken directly
       from lm, but when prelinking is involved and the prelink base
       address changes, we may need a different offset, we want to
       warn about the difference and compute it only once.  */
    CORE_ADDR l_addr;

This is not the load address.  Typically on a prelinked system where
everything works fine L_ADDR == 0 for everything.


> +   The function also checks if the address of the .dynamic section as
> +   calculated from the load address plus the section address in the
> +   shared object file matches the actual .dynamic address as given by
> +   the inferior's link map.

"checks" seems more like only a verification; but it in fact bases the
calculation on top of it.


> +   If they don't match, it tries to determine if the difference is due
> +   to prelink and adjusts the load address accordingly, warning the user.  */

There is (now) "info_verbose", in normal cases it adjusts the load address
silently as it is a normal state, without any warning.


/* Returns lm_info->l_addr, the amount by which addresses in the binary should
   be relocated to match the inferior.

   The function calculates the difference by comparing address of the
   PT_DYNAMIC segment as recognized by the dynamic linker (link_map->l_ld) and
   the ABFD VMA address of the ".dynamic" section.  The ABFD VMA address is
   already relocated according to the ABFD load address.

   If they don't match, GDB believes the difference is due to prelink and
   adjusts the load address accordingly.  User is given a warning if the
   difference alignment looks as if ABFD does not match the inferior.  */


I welcome if you can make the comment more understandable for the reader.


Thanks,
Jan


      reply	other threads:[~2011-07-04 20:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-04 19:51 Thiago Jung Bauermann
2011-07-04 20:34 ` Jan Kratochvil [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=20110704201605.GA9482@host1.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=bauerman@br.ibm.com \
    --cc=gdb-patches@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