Re: MIPS 64 bit addressing query

["Vinod pandarinathan" <vinod dot pandarinathan at gmail dot com>]

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