Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Aleksandar Ristovski <aristovski@qnx.com>
Subject: Re: [patch] nto-tdep.c - adjust addr_low addr_high
Date: Tue, 28 Jul 2009 11:29:00 -0000	[thread overview]
Message-ID: <200907281203.37720.pedro@codesourcery.com> (raw)
In-Reply-To: <4A6E141E.1080006@qnx.com>

On Monday 27 July 2009 21:54:54, Aleksandar Ristovski wrote:
> Pedro Alves wrote:
> > On Wednesday 08 July 2009 15:26:55, Aleksandar Ristovski wrote:
> > 
> >> This adjusts so->addr_low and so->addr_high for proper "info 
> >> sahredlibrary" output.
> > 
> >>   Index: gdb/nto-tdep.c
> >> ===================================================================
> >> RCS file: /cvs/src/src/gdb/nto-tdep.c,v
> >> retrieving revision 1.34
> >> @@ -315,6 +316,10 @@ nto_relocate_section_addresses (struct s
> >>  
> >>    sec->addr = nto_truncate_ptr (sec->addr + LM_ADDR (so) - vaddr);
> >>    sec->endaddr = nto_truncate_ptr (sec->endaddr + LM_ADDR (so) - vaddr);
> >> +  if (so->addr_low == 0)
> >> +    so->addr_low = LM_ADDR (so);
> > 
> > Isn't LM_ADDR an offset, not an absolute address?
> 
> In our case, it's absolute address of .text (that is why we 
> subtract vaddr as read from phdr).

Ah, I see.  You always get l_addr from the link map.

I take it you mean absolute address of the lowest segment -- if .text
isn't the lowest loaded section, then LM_ADDR will be lower
than the .text's virtual address in memory, IIUC.  Patch is OK.

I see now that 'nto-tdep.c:struct lm_info' is a 100% copy of
the solib-svr4.c version --- and it has to be so to keep binary
compatibility between the modules (why isn't this structure in a
shared header, hasn't this been a headache before?) --- but
it's comments end up being inaccurate for NTO:

    /* 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;

IIUC, you won't reach solib-svr4.c:LM_ADDR_CHECK's offset computing,
or it's warning on nto.  lm_info->lm_addr ends up unused too, IIUC.  This
makes me wonder if there's no better way of implementing (and getting rid
of) this NTO overriding of svr4_so_ops, e.g., with a gdbarch
property that would be checked on solib-svr4.c:LM_ADDR_CHECK.

Anyway, I'm diverging now.

> > 
> >> +  if (so->addr_high < sec->endaddr)
> >> +    so->addr_high = sec->endaddr;
> >>  }
> >>  
> >>  /* This is cheating a bit because our linker code is in libc.so.  If we
> > 


-- 
Pedro Alves


      reply	other threads:[~2009-07-28 11:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-08 14:27 Aleksandar Ristovski
2009-07-21 17:16 ` Aleksandar Ristovski
2009-07-24 15:41 ` Pedro Alves
2009-07-28  0:09   ` Aleksandar Ristovski
2009-07-28 11:29     ` Pedro Alves [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=200907281203.37720.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=aristovski@qnx.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