Re: the [de]register_frame_info definitions issues on Alpha
[ I will try to answer different mail at once, and sorry if you
receive twice, I messed up something ]
H.J. Lu writes:
> > In summary, I know I can use the latest glibc 2.0/2.1 from CVS and
> > compile it with egcs 1.1.1/Linux, but I do not _want_ to be forced to,
> > it introduces unecessary requirements in the way systems are
> > upgraded, and in the circulation of binaries between systems.
> >
>
> You can do whatever you want as long as you don't distribute binaries
> nor run binaries compiled on other systems.
Ok, sorry I was not clear, my concern was not about me, but about
debian users. And all this thread is not about the egcs that I
will use, but about the egcs that will go in the next standard
Debian/Alpha distribution (I am a debian developer).
> 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 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.
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).
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).
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
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?
md5sum:
c03dbe7c1c8d254e697aba6d7d0e0063 egcs-1.1.1-19990115-linux.diff
Zack Weinberg writes:
> HJ overstates the situation a bit. We are not doing anything to 2.0,
> and in fact you should NOT use egcs to compile libc 2.0 unless no
> other compiler works on the platform in question - that was how the
> __register_frame_info problem came up in the first place.
>
> However, in 2.1, we've decided to insist that libc export
> __register_frame_info and its friends, so that it isn't defined
> anywhere else (multiple copies can cause programs to crash). That
> means you have to use *some* version of egcs to compile libc 2.1. You
> don't have to use HJ's patched egcs 1.1.1. (In fact, I'd recommend
> that you don't use it - instead, examine each of his patches and
> decide whether to apply it yourself. Some of them are good, some are
> not.)
>
Actually the inclusion of register_frame_info in libc seems to have
been backported to 2.0 according to the ChangeLog. Anyway I repeat
again that since the beginning my only concern is about what should be
in crtbegin.o (my point being it should not contain an undefined
reference to register_frame_info but a weak definition of it, in order
to preserve binary compatibility between systems).
Loic
Reply to: