MIPS 64 bit addressing query

MIPS 64 bit addressing query

[Vinod pandarinathan]

Hi Experts,


I found that gdb6.4.1 is sign extending the
PC before comparing it to the breakpoint address[bpt->address].

Sign extension happens in mips-tdep.c

/* MIPS believes that the PC has a sign extended value.  Perhaps the
   all registers should be sign extended for simplicity? */

static CORE_ADDR
mips_read_pc (ptid_t ptid)
{
  return read_signed_register_pid (mips_regnum (current_gdbarch)->pc, ptid);
}
The target suspends at the breakpoint, but the debugger is not able to
identify the associated breakpoint as [unsigned value is compared to a
64 bit sign extended value].

We are using MIPS 3 ISA and since breakpoint is set at an address
where the 32nd bit is set to 1 the 64 bit sign extended values does
not compare with the unsigned
break point address.

Can you please explain how we can fix the problem? Should I sign
extend the break point address too ?


Thanks
Vinod.

Re: MIPS 64 bit addressing query

[David Daney]

Vinod pandarinathan wrote:
> Hi Experts,
>
>
> I found that gdb6.4.1 is sign extending the
> PC before comparing it to the breakpoint address[bpt->address].
>
> Sign extension happens in mips-tdep.c
>
> /* MIPS believes that the PC has a sign extended value.  Perhaps the
>    all registers should be sign extended for simplicity? */
>
> static CORE_ADDR
> mips_read_pc (ptid_t ptid)
> {
>   return read_signed_register_pid (mips_regnum (current_gdbarch)->pc, ptid);
> }
> The target suspends at the breakpoint, but the debugger is not able to
> identify the associated breakpoint as [unsigned value is compared to a
> 64 bit sign extended value].
>
> We are using MIPS 3 ISA and since breakpoint is set at an address
> where the 32nd bit is set to 1 the 64 bit sign extended values does
> not compare with the unsigned
> break point address.
>
> Can you please explain how we can fix the problem? Should I sign
> extend the break point address too ?
>   
I am running gdb-6.6 on mips64-linux (All of n32, n64 and o32 ABIs) with 
no apparent problems.

Perhaps you should upgrade.

David Daney

Re: MIPS 64 bit addressing query

[Daniel Jacobowitz]

On Sun, Aug 05, 2007 at 05:57:36PM -0700, Vinod pandarinathan wrote:
> We are using MIPS 3 ISA and since breakpoint is set at an address
> where the 32nd bit is set to 1 the 64 bit sign extended values does
> not compare with the unsigned
> break point address.
> 
> Can you please explain how we can fix the problem? Should I sign
> extend the break point address too ?

Wherever you got the zero extended address, there's the bug.  All
addresses should be sign extended when working with the MIPS target,
even most of the ones from the command line.

As David said, I suggest you upgrade before you try modifying GDB.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MIPS 64 bit addressing query

[Vinod pandarinathan]

Hi,

Thanks for the quick reply. I upgraded the debugger to gdb6.6 but
still seeing the same problem. I searched the newsgroup and found a
related thread

http://www.ecos.sourceware.org/ml/gdb/2006-10/msg00088.html

I checked mips-tdep.c where the function
set_gdbarch_integer_to_address uses mips_integer_to_address which sign
extends the 32 bit value. From the above thread it is suggested to use
unsigned integer extension. However I am still trying to find where
the zero extended address[bpt->address] is coming from.

Thank you
Vinod.



On 8/5/07, Daniel Jacobowitz <drow@false.org> wrote:
> On Sun, Aug 05, 2007 at 05:57:36PM -0700, Vinod pandarinathan wrote:
> > We are using MIPS 3 ISA and since breakpoint is set at an address
> > where the 32nd bit is set to 1 the 64 bit sign extended values does
> > not compare with the unsigned
> > break point address.
> >
> > Can you please explain how we can fix the problem? Should I sign
> > extend the break point address too ?
>
> Wherever you got the zero extended address, there's the bug.  All
> addresses should be sign extended when working with the MIPS target,
> even most of the ones from the command line.
>
> As David said, I suggest you upgrade before you try modifying GDB.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>

Re: MIPS 64 bit addressing query

[Daniel Jacobowitz]

On Mon, Aug 06, 2007 at 11:24:31AM -0700, Vinod pandarinathan wrote:
> set_gdbarch_integer_to_address uses mips_integer_to_address which sign
> extends the 32 bit value. From the above thread it is suggested to use
> unsigned integer extension.

That was specific to SH targets, not MIPS.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MIPS 64 bit addressing query

[Paul Koning]

>>>>> "Vinod" == Vinod pandarinathan <vinod.pandarinathan@gmail.com> writes:

 Vinod> Hi, Thanks for the quick reply. I upgraded the debugger to
 Vinod> gdb6.6 but still seeing the same problem. I searched the
 Vinod> newsgroup and found a related thread

 Vinod> http://www.ecos.sourceware.org/ml/gdb/2006-10/msg00088.html

 Vinod> I checked mips-tdep.c where the function
 Vinod> set_gdbarch_integer_to_address uses mips_integer_to_address
 Vinod> which sign extends the 32 bit value. From the above thread it
 Vinod> is suggested to use unsigned integer extension. However I am
 Vinod> still trying to find where the zero extended
 Vinod> address[bpt->address] is coming from.

The ecos thread is for a different architecture, the SH.  I don't know
about that one, but the MIPS rule is entirely clear -- 32-bit
addresses are sign extended, NOT zero extended, to make a 64-bit
address.  So if you're seeing problems because of a zero-extended
address, the fix is to track down where that comes from and make it
sign-extend instead.

	    paul

Re: MIPS 64 bit addressing query

[Vinod pandarinathan]

Thanks everyone for the details. Its still difficult to figure out
where the sign extension should happen.

We have a mips64 target but run mips32 binaries on the target.
The addresses are 32 bits in the executable file they are just loaded
into the symbol table as 32 bit addresses.

When the breakpoint is hit, symbol address from the symbol table is
not sign extended (bpt->address) and compared to sign extended program
counter which seems to cause the problem.

Does the sign extension happen when the addresses are stored in the
breakpoint structure in (set_raw_breakpoint) or even earlier when the
symbols are read from the executable ?

Thanks
Vinod.


On 8/6/07, Paul Koning <pkoning@equallogic.com> wrote:
> >>>>> "Vinod" == Vinod pandarinathan <vinod.pandarinathan@gmail.com> writes:
>
>  Vinod> Hi, Thanks for the quick reply. I upgraded the debugger to
>  Vinod> gdb6.6 but still seeing the same problem. I searched the
>  Vinod> newsgroup and found a related thread
>
>  Vinod> http://www.ecos.sourceware.org/ml/gdb/2006-10/msg00088.html
>
>  Vinod> I checked mips-tdep.c where the function
>  Vinod> set_gdbarch_integer_to_address uses mips_integer_to_address
>  Vinod> which sign extends the 32 bit value. From the above thread it
>  Vinod> is suggested to use unsigned integer extension. However I am
>  Vinod> still trying to find where the zero extended
>  Vinod> address[bpt->address] is coming from.
>
> The ecos thread is for a different architecture, the SH.  I don't know
> about that one, but the MIPS rule is entirely clear -- 32-bit
> addresses are sign extended, NOT zero extended, to make a 64-bit
> address.  So if you're seeing problems because of a zero-extended
> address, the fix is to track down where that comes from and make it
> sign-extend instead.
>
>            paul
>
>

Re: MIPS 64 bit addressing query

[Daniel Jacobowitz]

On Tue, Aug 14, 2007 at 01:20:34PM -0700, Vinod pandarinathan wrote:
> Does the sign extension happen when the addresses are stored in the
> breakpoint structure in (set_raw_breakpoint) or even earlier when the
> symbols are read from the executable ?

Should be back here.

What ABI and file format is your code?  I just last week worked on a
similar problem for N64 binaries in 32-bit ELF.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MIPS 64 bit addressing query

[Vinod pandarinathan]

Its an ELF 32-bit MSB MIPS-III executable with the following flags set
in the elf header.

  Flags:                             0x20001101, noreorder, 32bitmode,
o32, mips    3


Thanks
Vinod.

On 8/14/07, Daniel Jacobowitz <drow@false.org> wrote:
> On Tue, Aug 14, 2007 at 01:20:34PM -0700, Vinod pandarinathan wrote:
> > Does the sign extension happen when the addresses are stored in the
> > breakpoint structure in (set_raw_breakpoint) or even earlier when the
> > symbols are read from the executable ?
>
> Should be back here.
>
> What ABI and file format is your code?  I just last week worked on a
> similar problem for N64 binaries in 32-bit ELF.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>

Re: MIPS 64 bit addressing query

[Daniel Jacobowitz]

On Tue, Aug 14, 2007 at 02:51:57PM -0700, Vinod pandarinathan wrote:
> Its an ELF 32-bit MSB MIPS-III executable with the following flags set
> in the elf header.
> 
>   Flags:                             0x20001101, noreorder, 32bitmode,
> o32, mips    3

I don't get it.  If it's o32, why do you have 64-bit addresses at all?
Anyway, GDB should be automatically sign extending already in this
case.  Check the symbol readers.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MIPS 64 bit addressing query

[Vinod pandarinathan]

Thanks David. I am not sure why the executable is built with o32 and
MIPS III, but it looks like thats the problem here.

On 8/14/07, Daniel Jacobowitz <drow@false.org> wrote:
> On Tue, Aug 14, 2007 at 02:51:57PM -0700, Vinod pandarinathan wrote:
> > Its an ELF 32-bit MSB MIPS-III executable with the following flags set
> > in the elf header.
> >
> >   Flags:                             0x20001101, noreorder, 32bitmode,
> > o32, mips    3
>
> I don't get it.  If it's o32, why do you have 64-bit addresses at all?
> Anyway, GDB should be automatically sign extending already in this
> case.  Check the symbol readers.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>