Re: the [de]register_frame_info definitions issues on Alphag
>
> > However, in order to keep binary compatibility between different Linux
> > systems, I am not talking about different Debian machines built by
> > different Debian people at different times, it is referring to ALL
> > Linux machines based on glibc 2, including RedHat, Debian, ...., it i
> > s mandated to upgrade to the latest glibc 2.0/2.1 and egcs 1.1.1/Linux.
> > That is one reason we made those changes. It is required. Period.
>
> I am glad you also want to ensure binary compatibility on ALL machines
> based on glibc 2, so let's look at the situation:
> Alpha glibc2 systems I know:
> 1) Redhat 5.0,5.1,5.2 (the latest as far as I know)
> lx-~$cat /etc/redhat-release
> Red Hat Linux release 5.2 (Apollo)
> lx-~$nm --dynamic /lib/libc-2.0.7.so | grep register_fr
> lx-~$gcc -v
> Reading specs from /usr/lib/gcc-lib/alpha-redhat-linux/egcs-2.90.29/specs
> gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)
>
> 2) Debian/Alpha (that altough never officially released has a number
> of users)
> It did either have register_frame_info in its libc until
> recently.
>
>
> So to ensure binary-compatibility executables should not depend on
> the register_frame_info function.
Let me repeat myself again:
However, in order to keep binary compatibility between different Linux
systems, I am not talking about different Debian machines built by
different Debian people at different times, it is referring to ALL
Linux machines based on glibc 2, including RedHat, Debian, ...., it is
mandated to upgrade to the latest glibc 2.0/2.1 and egcs 1.1.1/Linux.
That is one reason we made those changes. It is required. Period.
It is for the present and future glibc 2 based Linux systems. You
haven't seen them in the older Linux systems. That is exactly the
bug we are trying to fix.
>
> Let be sure there is no misunderstanding: I fully understand all libc
> starting from now must include register_frame_info, what I want to check
> is that C-only executables do not _rely_ on it. So all I am
> concerned about, is the crtbegin.o shipped with egcs and not libc itself.
>
That is why I made egcs 1.1.1/Linux. It modifies crt*.o for that
purpose.
>
> H.J. Lu writes:
> > # objdump --dynamic-sym /usr/bin/gcc | grep __deregister_frame_info
> > 08048ca4 DF *UND* 000000a8 __deregister_frame_info
>
> That's the kind of executables that would be better to avoid if
> possible, your gcc will probably not run on a standard Redhat5.2
> system (ok, it isn't important in the particular case of gcc, but not
> for other executables).
That is why I said you need to upgrade to the latest glibc 2.0.
>
> H.J. Lu writes:
> > > 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.
> > >
> >
> > Wait a second. My egcs-1.1.1.diff.12 is removed from the final egcs
> > 1.1.1 19990115/Linux. Please use the patch at
> >
> > ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/egcs-1.1.1-19990115-linux.diff.gz
> >
> > Please don't use any previous patches.
>
> Can you clarify a few point about your official egcs-1.1.1-19990115-linux.
> First are the binary really available? I could not find them on the sites mentioned in
> your announcement (http://www.linuxhq.com/lnxlists/linux-gcc/lg_9901/msg00061.html).
I have binaries for alpha and glibc2/x86. But I have difficulties to
obtain libc5/x86 binaries since I am no longer running libc 5. I am
still working on that.
>
> Then the config/alpha/crtbegin.asm does not make any reference to
> register_frame_info, which would be perfect for Debian (preserve binary
> compatibility). But this is inconsistent with the result that you mentioned
> previously with "objdump --dynamic-sym /usr/bin/gcc" (and also inconsistent
That is on x86.
# objdump --dynamic-sym /usr/bin/gcc | grep frame
# uname -a
Linux creek.lucon.org 2.1.131 #10 Sat Dec 12 16:06:31 PST 1998 alpha unknown
> with other archs that AFAIK generate crtbegin.o from crtstuff.c).
> when I recompile a pristine egcs-1.1.1-19990115-linux with itself I do not find
> the register-frame_info symbol in the result? The output of crtbegin.o for
> a pristine egcs-1.1.1-19990115-linux here is:
> 0000000000000000 a *ABS*
> 0000000000000000 ? __CTOR_LIST__
> 0000000000000000 ? __DTOR_LIST__
> 0000000000000000 t __do_global_dtors_aux
>
> Is it consistent with yours? Does your gcc/config/crtbegin.asm mention
> register_frame_info?
>
Yes.
--
H.J. Lu (hjl@gnu.org)
Reply to: