Re: RFA: print addresses that are longer than pointers, take two

[Jim Blandy <jimb at zwingli dot cygnus dot com>]

> > This also rewrites the mask generation in a way which I think is
> > overflow-free, without needing to pull the wool over the compiler's
> > eyes.
> [...]
> > ! 	if (TYPE_CODE (type) != TYPE_CODE_PTR)
> > ! 	  /* When building the mask, avoid shifts larger or equal than
> > ! 	       the width of a CORE_ADDR.  */
> > ! 	  addr &= ((((CORE_ADDR) 1 << (TARGET_PTR_BIT - 1)) - 1) << 1) + 1;
> 
> It's not really the compiler that needs the wool pulled over it's eyes,
> it's the architecture.  Shift instructions are notorious for
> behaving differently on different architectures when presented with
> shift operands that are out of bounds.

Oh, I grant that shift distances larger than a word are problematic.
The "wool-pulling" I was referring to was the use of a temporary
variable to (if I understand correctly) complicate the code beyond the
compiler's ability to analyze it, thereby silencing a spurious
warning.


> For this reason, my first thought was that your code could have
> problems.  But after thinking about it a some more I remembered that
> it is a fundamental assumption in gdb that the length in bits of a
> CORE_ADDR is greater than or equal to TARGET_PTR_BIT.  Which means
> that the amount being shifted will never be greater or equal to the
> length of bits in a CORE_ADDR.  (I like the sneaky way that you
> subtract 1 from TARGET_PTR_BIT to narrowly avoid the problem.)

Right.  I believe everything in that expression is well-defined.