Re: [Problem] gnu-v3 abi loaded wronly.

[Daniel Jacobowitz <drow@mvista.com>]

On Wed, Sep 18, 2002 at 04:52:54PM +0200, Pierre Muller wrote:
> At 16:51 18/09/2002 , Daniel Jacobowitz a écrit:
> >On Wed, Sep 18, 2002 at 03:35:41PM +0200, Pierre Muller wrote:
> > > At 15:17 18/09/2002 , Daniel Jacobowitz a écrit:
> > > >On Wed, Sep 18, 2002 at 12:00:22PM +0200, Pierre Muller wrote:
> > > > > 
> > > > > 
> > > > >    The code for loading gnu-v3-abi is symply to
> > > > > look if there is a minimal symbol starting with 
> > > > >   _Z
> > > > > underscore followed by a capital Z:
> > > > > 
> > > > > Why is this test so imprecise?
> > > > > To what symbol generated by GCC
> > > > > v3 does it correspond?
> > > > > Why is it not a full name test?
> > > > > 
> > > > > Currently this creates a problem for me when
> > > > > I mix GCC 2.95.X code with Free Pascal generated
> > > > > code on linux, because Free Pascal defines
> > > > > a minimal symbol _ZONE_NAMES
> > > > > that is recognized as a GCC v3 marker...
> > > > > 
> > > > > if you create a c code with a static variable 
> > > > > called _Zzzz
> > > > > you will probably get the same error...
> > > > > 
> > > > > I consider this to be a bug in GDB, but 
> > > > > I would like to get the arguments of the 
> > > > > interested people.
> > > >
> > > >Every mangled name in v3 starts with _Z.  We've always held that if you
> > > >use names in the reserved namespace for your own functions, you get
> > > >what you deserve - but we hadn't thought any other compilers used this
> > > >namespace...
> > > >
> > > >We could require that the first _Z symbol be a valid mangled C++ name.
> > > >That would sometimes break the test in the other direction if you had
> > > >v3 code linked with Free Pascal code.  Does Free Pascal define a large
> > > >number of symbols starting with _Z, or just the one?  If it's just the
> > > 
> > > No, its just a static variable that starts with Z 
> > > so there can be others around...
> > > (Free Pascal adds a leading underscore to all
> > > static variables, regardless of what GCC does...)
> >
> >Blech.
> >
> > > >one we can fix this by checking all _Z symbols until we find one that
> > > >is v3 mangled.
> > > 
> > > I started to write a Free Pascal version of xx-abi.c
> > > because there are other object/class related problems 
> > > with Free Pascal.
> > > 
> > > The other solution would be to check for "fpc_compiled"
> > > and then declare that its an Free Pascal  compiled object,
> > > but that would not solve the problem of my
> > > IDE that has both Free Pascal code and
> > > GCC code of  libgdb...
> > > because in that case it would mean that we need to decide 
> > > which abi to use depending on the source file type,
> > > would that be possible?
> >
> >GDB is definitely not set up to do this.  If you mix code that requires
> >particular ABI support, you'll just confuse it hopelessly.  For
> >instance, we can determine the ABI without debug information (though we
> >don't use it for much in that case) - which ABI do you pick if two are
> >marked?
> >
> >For C++ this is generally OK.  No one except Apple is crazy enough to
> >try to mix-n-match.  If Free Pascal code is commonly linked with C++
> >code, then we need to think about this further.
> 
> I have no C++ code in my problem...
> Libgdb is only C code, but the problem arises nevertheless...

Then there should be no problem with setting a new free-pascal ABI. 
The ABI only specifies things C++ (and now Pascal) specific; C code
doesn't use it at all.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer