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

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

[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

[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

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