the [de]register_frame_info definitions issues on Alpha
Matthias Klose writes:
> [CC to HLU]
>
> Loic Prylli writes:
> > I have tried the gdb from (Mikolaj J. Habryn) and got the following
> > error:
> >
> > ./gdb: error in loading shared libraries
> > : undefined symbol: __deregister_frame_info
> >
> > [skip description of register_frame_info issue]
>
> Just the question which Debian version of egcs do you use? The current
> one is egcs-1.1.1-4.
Yes I have tried the latest source from debian/slink
> In 2.91.60-4 there is another HLU patch to bring it to his egcs Linux
> release. Please tell me if I should leave out the hjl-12 patch.
I have seen the 0hjl-19990115-linux patch that add the weak
declarations.
That was exactly what I was referring to when I said:
> > I think the right solution is to patch the crtbegin file in egcs, to
> > include a weak prototype of [de]register_frame_info, setting it to
> > a dummy function. Looking at the code I think this was the intention
> > of the author to do something similar because he included weak prototypes
> > of the symbol, and do not call the function int them if they point to
> > "zero". But he forgot to actually put a default definition, so the weak
> > protype is ingored in this cases.
My point is that the last HLU patch looks buggy because it creates a weak
undefined symbol, which does not solve anything (it is considered by
the ld-linux.so as an undefined one). We need a real weak
symbol with a real default definition. I just propose to complete it
by adding the default definition. No need to remove the hlu-12 patch
which I suppose was created to fill some needs (I trust HLU for that).
> HLU told me, that it would be sufficient to recompile glibc with the
> egcs-1.1.1 Linux release.
Unless I missed something (maybe there is some ugly hack to transform a
weak undefined symbol into a weak symbol defined as zero in some
binutils or ldso release),it does not work. Moreover the problem
is not really the libc per se which is fine, but the executables that
depends on the symbol (and that creates a unwanted dependency on the
latest Debian libc).
>
> In gcc/config/t-linux all symbols are defined which should not be
> exported to shared libs.
Do you mean exported _by_ shared libs? I am not sure I understand this
mechanism, but I do not feel it could solve our problem, we certainly
want register_frame_info to be a normal "overloadable" symbol.
Regards,
Loic
Reply to: