This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Document lm_addr_check.
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- Cc: gdb-patches ml <gdb-patches at sourceware dot org>
- Date: Mon, 4 Jul 2011 22:16:05 +0200
- Subject: Re: [RFA] Document lm_addr_check.
- References: <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