Re: MIPS sign extension of addresses

[Andrew Cagney <ac131313 at ges dot redhat dot com>]

> >  Well, that seems the reason of the trouble -- for MIPS addresses in
> > object and executable files should be treated as signed and bfd_vma should
> > be a signed type since that's how MIPS works. 
>
> So does that mean that it would be more desirable if the MIPS ports used
> signed long long for bfd_vma/CORE_ADDR instead of unsigned long long?
>
> I'm willing to work on making that happen if that is the consensus for
> making MIPS support more consistent with how the hardware works.
>
> I've not yet checked, but are there fundamental reasons why bfd_vma
> or CORE_ADDR have to be unsigned?
I don't think it will help.  I think it will also hinder the situtation 
where BFD/GDB are supporting multiple architectures - one signed and one 
unsigned.

``signed long long'' and ``unsigned long long'' would only show their 
true colours if there was a ``signed/unsigned long long long'' type.

Anyway, several problems occure:

- code extracts a small value and gets its sign extension wrong
Here, I think all we can do is continue tracking down cases.

- code does boundary arrithmetic (0x7fffffff+1 == 0xffffffff80000000)
Here, it happens so rarely that it isn't worth worrying about. 
Eventually someone will implement a CORE_ADDR object and that will 
really fix the problem.

- code doesn't use CORE_ADDR and {U]LONGEST correctly (occures when 
sizeof (CORE_ADDR) < sizeof ([U]LONGEST) --- i386.
A CORE_ADDR object would fix this to.  However, being more careful 
wouldn't hurt.

Andrew