C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Alexandre Oliva]

The C++ ABI v3 uses the least significant bit of the pfn to tell
non-virtual from virtual functions.  The problem is that, on
architectures that don't impose any alignment requirements on
beginning of functions, the assumption that pfn&1 == 0 for pointers to
non-virtual member functions doesn't always hold.  This breaks C++ on
at least avr, elxsi, mn10200, mn10300 and pj.

I suppose we could just bump FUNCTION_BOUNDARY up, but I'd rather not
do it on targets in which code size is an important issue.  That's the
case of mn10300.

It would be great if we could enforce 2-byte alignment only on
non-virtual member functions whose addresses were taken to construct
pointers to member functions, but, since we can't tell in advance
whether the address of a non-virtual member function was taken, we'd
have to assume at least all non-virtual member functions have to be
aligned to 2 * BITS_PER_UNIT.

Another possibility I see is to arrange for the bit used to tell
non-virtual from virtual member functions in pointers to members be
moved to the delta field of the pointer to member, in case
FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT.  This would be a diversion from
the IA64 C++ ABI, but it makes more sense to me, for targets in which
function addresses are not guaranteed to be even addresses.

Opinions?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Neil Booth]

Alexandre Oliva wrote:-

> The C++ ABI v3 uses the least significant bit of the pfn to tell
> non-virtual from virtual functions.  The problem is that, on
> architectures that don't impose any alignment requirements on
> beginning of functions, the assumption that pfn&1 == 0 for pointers to
> non-virtual member functions doesn't always hold.  This breaks C++ on
> at least avr, elxsi, mn10200, mn10300 and pj.

Presumably those archs where you can't use the low bit have a small
memory space anyway.  Maybe the address types are wide enough that you
can use the high bit instead?  That'd allow you to just define a macro

VIRTUAL_FUNCTION_BIT

and mask with that.  Or maybe I have no idea what I'm talking about :-)

Neil.

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Alexandre Oliva]

On Apr  6, 2001, Neil Booth <neil@daikokuya.demon.co.uk> wrote:

> Presumably those archs where you can't use the low bit have a small
> memory space anyway.

But still, at least some of them have MMUs, so there really isn't much
relationship between the amount of memory and the addresses in which
it's mapped.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Jim Wilson]

In article < ork84ys5bq.fsf@guarana.lsd.ic.unicamp.br > you write:
>The C++ ABI v3 uses the least significant bit of the pfn to tell
>non-virtual from virtual functions.

There are also targets that use the low-order bit of the PC to determine
processor mode.  Two prominent examples are arm/thumb and mips/mips16.
If an address has the low bit set, then that means it is using the 16-bit
compressed instruction set instead of the normal 32-bit instruction set.

This is also a problem for word addressable machines.  In that case, all
bits of the address are significant, and there aren't any unused lower-bits
that can be used by the C++ front end.  There are several gcc ports to DSPs
that would have this problem.

Jim

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[DJ Delorie]

Jim Wilson <wilson@cygnus.com> writes:
> This is also a problem for word addressable machines.

I imagine the x86 would have problems also.  Functions can start on
*any* address, even odd ones.  The fact that gcc puts them on aligned
addresses by default is a convention, not a cpu requirement.

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Richard Earnshaw]

> Alexandre Oliva wrote:-
> 
> > The C++ ABI v3 uses the least significant bit of the pfn to tell
> > non-virtual from virtual functions.  The problem is that, on
> > architectures that don't impose any alignment requirements on
> > beginning of functions, the assumption that pfn&1 == 0 for pointers to
> > non-virtual member functions doesn't always hold.  This breaks C++ on
> > at least avr, elxsi, mn10200, mn10300 and pj.
> 
> Presumably those archs where you can't use the low bit have a small
> memory space anyway. 

Nope.

> Maybe the address types are wide enough that you
> can use the high bit instead?  
Nope.

>That'd allow you to just define a macro
> 
> VIRTUAL_FUNCTION_BIT
> 
> and mask with that.  Or maybe I have no idea what I'm talking about :-)

All 32 bits in an ARM pointer have meaning in some context or another.  
There are no spare ones for this sort of diddling.

I think you need to find another way to represent this information.

R.

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Dave Korn]

> > Alexandre Oliva wrote:-
> >
> > > The C++ ABI v3 uses the least significant bit of the pfn to tell
> > > non-virtual from virtual functions.  The problem is that, on
> > > architectures that don't impose any alignment requirements on
> > > beginning of functions, the assumption that pfn&1 == 0 for pointers to
> > > non-virtual member functions doesn't always hold.  This breaks C++ on
> > > at least avr, elxsi, mn10200, mn10300 and pj.

From: "Richard Earnshaw" <rearnsha@arm.com>
> Nope.

> Nope.

> All 32 bits in an ARM pointer have meaning in some context or another.
> There are no spare ones for this sort of diddling.
>
> I think you need to find another way to represent this information.


  Seconded.  I was working on m68ks around the transition from the '000 to
'020.  The address bus got 8 bits wider.  Suddenly addresses and hence
pointers went from 24 significant bits to 32 significant bits, and all the
software that had been using the high byte of a pointer to store flag bits
broke hideously.  This caused a lot of pain on Macs, where it was a common
technique, and much less on Amigas, where it had been warned against,
forbidden even, from the outset in the ABI / coding standards.

  The lesson should be learned.  Don't try and hide extra data in pointers:
their format belongs to the CPU and is not under your control.

          DaveK

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Alexandre Oliva]

On Apr  6, 2001, Jim Wilson <wilson@cygnus.com> wrote:

>In article < ork84ys5bq.fsf@guarana.lsd.ic.unicamp.br > you write:

>> The C++ ABI v3 uses the least significant bit of the pfn to tell
>> non-virtual from virtual functions.

> There are also targets that use the low-order bit of the PC to determine
> processor mode.

Good point.  I think this is enough of a reason for us to have a
target configuration flag to switch between two different
representations of pointers to member functions.  I wonder how GDB is
going to be able to tell one representation from the other...  Perhaps
it's going to have to be hard-coded in GDB?

> This is also a problem for word addressable machines.  In that case, all
> bits of the address are significant, and there aren't any unused lower-bits
> that can be used by the C++ front end.

Here's the approach I propose to work around this problem.  I haven't
got to setting PTRMEMFUNC_VBIT_IN_DELTA for any targets.  Are there
any architectures supported by GCC other than MIPS and ARM that would
require this setting?  Should these be dependent on any particular
command-line flags (given that using the lowest bit of pfn is
certainly more efficient than having to shift delta)?

Is it safe to use arithmetic SHIFTs instead of letting the compiler
choose them instead of DIVs and MULTs?  For some reason, on
mn10300-elf, the div makes it to the generated code, which we
certainly don't want.

This was not thoroughly tested yet, as it's just a proposal of how to
approach the problem.  In case people agree this is the way to go,
I'll go ahead and test it on a few targets.  But something like this
should definitely go in 3.0, to avoid ABI changes in the future.

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Joern Rennecke]

 Is it safe to use arithmetic SHIFTs instead of letting the compiler
> choose them instead of DIVs and MULTs?  For some reason, on
> mn10300-elf, the div makes it to the generated code, which we
> certainly don't want.

A signed division is not a portable way to extract a bit.  And for
negative values, it just doesn't work.
Why don't you use an unsigned division or a logical shift?

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Alexandre Oliva]

On Apr  9, 2001, Joern Rennecke <amylaar@redhat.com> wrote:

>  Is it safe to use arithmetic SHIFTs instead of letting the compiler
>> choose them instead of DIVs and MULTs?  For some reason, on
>> mn10300-elf, the div makes it to the generated code, which we
>> certainly don't want.

> A signed division is not a portable way to extract a bit.

I don't want to extract a bit.  I want to extract the remaining bits.
The delta was shifted left (or multiplied by 2) to make room for the
vbit; now I want the delta back.  It's a signed offset.  The question
is : does GCC's notion of arithmetic shift, in the tree level,
guarantee sign-extension semantics, or do we really have to use
TRUNC_DIV, and I have to figure out why the heck it's not being
converted to an arithmetic shift on mn10300-elf, given that the asr
opcode does exactly the right thing.

> And for negative values, it just doesn't work.

Doh.  Never mind.  I *does* work.  It's TRUNC_DIV that doesn't, for
what I need.  I really need a right shift with sign extension:

     3 >> 1 == 1
     2 >> 1 == 1
     1 >> 1 == 0
     0 >> 1 == 0
0xffff >> 1 == 0xffff
0xfffe >> 1 == 0xffff
0xfffd >> 1 == 0xfffe
0xfffc >> 1 == 0xfffe

Does RSHIFT_EXPR guarantee the preservation of the most significant
(sign) bit?  Does it guarantee the semantics above?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Joern Rennecke]

> Doh.  Never mind.  I *does* work.  It's TRUNC_DIV that doesn't, for
> what I need.  I really need a right shift with sign extension:

I was talking about signed division.  I.e. TRUNC_DIV.  So we agree on
that point.

> Does RSHIFT_EXPR guarantee the preservation of the most significant
> (sign) bit?  Does it guarantee the semantics above?

According to c-tree.texi, it does.

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 *BITS_PER_UNIT

[Mark Mitchell]

I think this all makes sense.

I should have thought of this issue when implementing the new ABI;
somehow, it didn't occur to me.

I would sugest that if you're going to use an enum to represent
different choices about representation here (which seems reasonable)
that you have the TARGET_ macro evaluate to an enum, rather than a
boolean.  That would be simpler.  Have it default to
ptrmemfunc_vbit_in_pfn in defaults.h, and then you can eliminate the
conditional compilation in decl.c.

Thank you for taking on the task of fixing the problem.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Andrew Cagney]

Alexandre Oliva wrote:
> 
> On Apr  6, 2001, Jim Wilson <wilson@cygnus.com> wrote:
> 
> >In article < ork84ys5bq.fsf@guarana.lsd.ic.unicamp.br > you write:
> 
> >> The C++ ABI v3 uses the least significant bit of the pfn to tell
> >> non-virtual from virtual functions.

> > There are also targets that use the low-order bit of the PC to determine
> > processor mode.
> 
> Good point.  I think this is enough of a reason for us to have a
> target configuration flag to switch between two different
> representations of pointers to member functions.  I wonder how GDB is
> going to be able to tell one representation from the other...  Perhaps
> it's going to have to be hard-coded in GDB?

Remember, nothing in GDB is hard coded (only half :-^).

Either the v3 ABI would need to specify the exact mechanism that is
valid for ISA foo (i.e. GDB would would be wired to assume that all MIPS
use mechanism XYZ) or the debug/object info would need to describe the
mechanism being used so that GDB could adjust its self accordingly.

	Andrew

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Daniel Berlin]

On Tue, 17 Apr 2001, Andrew Cagney wrote:

> Alexandre Oliva wrote:
> >
> > On Apr  6, 2001, Jim Wilson <wilson@cygnus.com> wrote:
> >
> > >In article < ork84ys5bq.fsf@guarana.lsd.ic.unicamp.br > you write:
> >
> > >> The C++ ABI v3 uses the least significant bit of the pfn to tell
> > >> non-virtual from virtual functions.
>
> > > There are also targets that use the low-order bit of the PC to determine
> > > processor mode.
> >
> > Good point.  I think this is enough of a reason for us to have a
> > target configuration flag to switch between two different
> > representations of pointers to member functions.  I wonder how GDB is
> > going to be able to tell one representation from the other...  Perhaps
> > it's going to have to be hard-coded in GDB?
>
> Remember, nothing in GDB is hard coded (only half :-^).
>
And when it comes to C++ stuf, i refuse to hard code any more stuff, after
just spending months cleaning up the crud from 5 years of doing that.
> Either the v3 ABI would need to specify the exact mechanism that is
> valid for ISA foo (i.e. GDB would would be wired to assume that all MIPS
> use mechanism XYZ) or the debug/object info would need to describe the
> mechanism being used so that GDB could adjust its self accordingly.

It's easiest to do this in debug info.
At least, for dwarf (I dunno how tod ot he same in stabs).
In the type die of the ptr-to-member die, just add a GCC specific
attribute that says which bit to check for virtuality, and i'll modify
gdb to handle it right (by telling the C++ ABI abstraction layer which
bit to
check)
> > 	 Andrew >

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Richard Earnshaw]

aoliva@redhat.com said:
> I don't want to extract a bit.  I want to extract the remaining bits.
> The delta was shifted left (or multiplied by 2) to make room for the
> vbit; now I want the delta back.  It's a signed offset.  

This is OK, provided that you can guarantee that the left shift won't 
cause the "sign" bit to change value.  That is

	((X << 1) MOD size) >> 1 == X

for all interesting values of X.

R.

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Alexandre Oliva]

On Apr 18, 2001, Richard Earnshaw <rearnsha@arm.com> wrote:

> aoliva@redhat.com said:
>> I don't want to extract a bit.  I want to extract the remaining bits.
>> The delta was shifted left (or multiplied by 2) to make room for the
>> vbit; now I want the delta back.  It's a signed offset.  

> This is OK, provided that you can guarantee that the left shift won't 
> cause the "sign" bit to change value.

Since the delta is as wide as a pointer, in order for a left-shift to
modify its sign bit we'd need a single C++ object that takes more than
half the address space of a machine.  Actually, we need a C++ object
so complicated that one of its bases ends up with such a large offset.
I believe we can assume no such objects are never going to be defined.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Jason Merrill]

>>>>> "Daniel" == Daniel Berlin <dan@www.cgsoftware.com> writes:

> And when it comes to C++ stuf, i refuse to hard code any more stuff, after
> just spending months cleaning up the crud from 5 years of doing that.

>> Either the v3 ABI would need to specify the exact mechanism that is
>> valid for ISA foo (i.e. GDB would would be wired to assume that all MIPS
>> use mechanism XYZ) or the debug/object info would need to describe the
>> mechanism being used so that GDB could adjust its self accordingly.

> It's easiest to do this in debug info.
> At least, for dwarf (I dunno how to do the same in stabs).
> In the type die of the ptr-to-member die, just add a GCC specific
> attribute that says which bit to check for virtuality, and i'll modify
> gdb to handle it right (by telling the C++ ABI abstraction layer which
> bit to check)

So you'll hardcode the two possible representations, and rely on GCC to
tell you which one to use?  I suppose that's reasonable.

I'd rather put any special ABI attributes in the DW_TAG_compilation_unit,
to avoid repetition.

Jason

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Daniel Berlin]

On 16 May 2001, Jason Merrill wrote:

> >>>>> "Daniel" == Daniel Berlin <dan@www.cgsoftware.com> writes:
>
> > And when it comes to C++ stuf, i refuse to hard code any more stuff, after
> > just spending months cleaning up the crud from 5 years of doing that.
>
> >> Either the v3 ABI would need to specify the exact mechanism that is
> >> valid for ISA foo (i.e. GDB would would be wired to assume that all MIPS
> >> use mechanism XYZ) or the debug/object info would need to describe the
> >> mechanism being used so that GDB could adjust its self accordingly.
>
> > It's easiest to do this in debug info.
> > At least, for dwarf (I dunno how to do the same in stabs).
> > In the type die of the ptr-to-member die, just add a GCC specific
> > attribute that says which bit to check for virtuality, and i'll modify
> > gdb to handle it right (by telling the C++ ABI abstraction layer which
> > bit to check)
>
> So you'll hardcode the two possible representations, and rely on GCC to
> tell you which one to use?  I suppose that's reasonable.

Well, it's much harder to do it without *some* type of gcc information.
Otherwise, we have a case of GCC knowing the real answer, and GDB having
to guess, which never ends up well. :)

>
> I'd rather put any special ABI attributes in the DW_TAG_compilation_unit,
> to avoid repetition.

This is fine too. In fact, any way you think is good to communicate it to
gdb, i'm fine with.

>
> Jason
>

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Joern Rennecke]

> are there really architectures where there is no penalty for having
> odd-aligned function addresses? Hard to believe! Of course there are
> architectures where there is no *hard requirement* for alignment, but
> one would almost certainly expect a performance penalty. On the x86
> for example, it is quite important to give decent alignment to jump
> targets from an efficiency point of view.

AFAIK there are also architectures where word size, unit size and function
boundary are all the same.

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Jamie Lokier]

dewar@gnat.com wrote:
> <<I think that's not the main problem.  The problem is that we have an
> implicit assumption hidden deep inside the C++ front-end, and there's
> no validation anywhere preventing a definition of FUNCTION_BOUNDARY
> from breaking violating this assumption.
> >>
> 
> Well that's a very fair comment, most certainly this assumption needs to
> be documented at the top level, and an explicit check of FUNCTION_BOUNDARY
> as well as large documentation surrounding it is most appropriate :-)

Or just follow the original suggesetion of using a different bit when
FUNCTION_BOUNDARY == 1.

-- Jamie

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[dewar]

<<I think that's not the main problem.  The problem is that we have an
implicit assumption hidden deep inside the C++ front-end, and there's
no validation anywhere preventing a definition of FUNCTION_BOUNDARY
from breaking violating this assumption.
>>

Well that's a very fair comment, most certainly this assumption needs to
be documented at the top level, and an explicit check of FUNCTION_BOUNDARY
as well as large documentation surrounding it is most appropriate :-)

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Alexandre Oliva]

On Apr  6, 2001, dewar@gnat.com wrote:

> Well I would say that ancient architectures like Z80 can afford to pay
> 0.5 bytes/extra per function if they have to :-)

I think that's not the main problem.  The problem is that we have an
implicit assumption hidden deep inside the C++ front-end, and there's
no validation anywhere preventing a definition of FUNCTION_BOUNDARY
from breaking violating this assumption.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[dewar]

Well I would say that ancient architectures like Z80 can afford to pay
0.5 bytes/extra per function if they have to :-)

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[Jamie Lokier]

dewar@gnat.com wrote:
> are there really architectures where there is no penalty for having
> odd-aligned function addresses? Hard to believe!

Sure, Z80 :-)

-- Jamie

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT

[dewar]

are there really architectures where there is no penalty for having
odd-aligned function addresses? Hard to believe! Of course there are
architectures where there is no *hard requirement* for alignment, but
one would almost certainly expect a performance penalty. On the x86
for example, it is quite important to give decent alignment to jump
targets from an efficiency point of view.