This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] nto-tdep.c - adjust addr_low addr_high

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  If we
> > 

Pedro Alves

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]