Re: Why does mips define elf_backend_sign_extend_vma to true?

["H . J . Lu" <hjl@lucon.org>]

On Wed, Aug 08, 2001 at 11:18:05AM -0400, Andrew Cagney wrote:
> 
> You might need to find a simpler test!
> 

If it is that simple, shouldn't you have caught it long time ago?

> 
> > The problem is the 64bit BFD does the sign extension to the section
> > addresses which have the bit 31 set. Gdb cannot find 0x8011c530 in
> > those ranges. You may say oh, let's fix gdb to do
> > 
> > (gdb) p printk
> > $1 = {int (char *)} 0xffffffff8011c530
> > 
> > I don't think it will be useful to me. I don't think I can set a break
> > pount at 0xffffffff8011c530. The sign extension here is only the
> > artifact of the 64bit BFD. My mips target is 32bit.
> 
> 
> There is a bug but the underlying problem is the oposite of what you 
> claim.  Something is breaking that simple always sign-extend rule 
> (forgetting to sign extend something) and, as a consequence, the symbol 
> lookup is failing.
> 

I am willing to buy it. The immediate problem is in

struct obj_section *
find_pc_sect_section (CORE_ADDR pc, struct sec *section)
{
  struct obj_section *s;
  struct objfile *objfile;

  ALL_OBJSECTIONS (objfile, s)
    if ((section == 0 || section == s->the_bfd_section) &&
        s->addr <= pc && pc < s->endaddr)
      return (s);

  return (NULL);
}

s->addr and s->endaddr came from BFD with sign extension. But `pc' is
not, which has the bit 31 set. All of them have the type of CORE_ADDR.
Any suggestions? I am not sure if it is the only problem in gdb.


H.J.