From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H . J . Lu" To: Andrew Cagney Cc: "Maciej W. Rozycki" , Richard Henderson , David B Anderson , gdb@sourceware.cygnus.com, binutils@sourceware.cygnus.com Subject: Re: Why does mips define elf_backend_sign_extend_vma to true? Date: Wed, 08 Aug 2001 09:02:00 -0000 Message-id: <20010808090249.A28467@lucon.org> References: <20010807232102.A19636@lucon.org> <20010808072922.C26704@lucon.org> <3B7151C1.4030203@cygnus.com> <20010808080306.C26983@lucon.org> <3B71582D.4050003@cygnus.com> X-SW-Source: 2001-08/msg00070.html 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.