|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] RedHat 7.1 glibc2.1 Backward compat - revisited
|
On Fri, May 25, 2001 at 10:09:14AM -0400, Mental wrote:
> On Thu, May 24, 2001 at 11:44:49PM -0400, Greg Lopp wrote:
> > Unstable? The folks at redhat seem to think that gcc 2.96 is more
> > standards compliant than the kernel code.
> > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=20593 suggests
> > that all this fuss is over some syntax "errors". What is all this
> > "binary incompatible" stuff coming from? To restate an earlier
> > question : can anyone point me to a decent _technical_ explanation of
> > this problem?
>
> All the fuss is about changes in gcc. Gcc does some asm stuff differnetly
> than it used to. Compilers and kernels are pretty complex. The lkml faq
> explains why there's a recomended compiler for the kernel source tree.
>
> If you're interested in the "binary incompatible" nonsense, read up on
> assembler languages.
Yea, uh, that's how I earn a living. I'm currently on the tail end of
a project to migrate some embedded code from one toolset (Watcom 10a,
MSC and MASM in DOS6 ... all circa 1993) to another (someone decided
on CAD/ul. Nobody else would recognize far pointers...). I regularly
wrestle with endianness and stack frames. I know what these kinds of
problems are. I just want to know what this problem is specificaly.
> You never hear about it because really, its the
> compilers job to do it properly for you. Properly being
> 'consistantly'.
I'm reminded of a story from a company I worked for back in college.
The owners told of a bug they encountered early in their development.
A common optimization for multiplication for powers of two is to
perform a binary shift. They eventually tracked down their code's
unpredicable to the fact that their compiler was generating rotate opcodes
rather than shift opcodes.
Before this toolset migration, I was adding a feature to our bootstrap
and saw our compiler (Watcom 10a) generate asm which bore no
reflection to the original source and could not fail to hang the
processor. gcc and CAD/ul's cc result in similar problems. But all
is well in each if you turn off the optimization flags.
> The gcc problem resulted from changes to gcc. THese same problems can
> happen when you compile the kernel with a different compiler... say egcs
> or pgcc. They're untested and do things differently than the 'recomended
> gcc' does.
>
> The point of the whole issue was that RH threw away the control. The
> compiler was a constant. So when there was a bug, was it in the compiler,
> or in the kernel. It made problems harder to track down.
>
> If you want a technical explanation, go search the kernel mailing list.
Lots of complaining there. No real substance. Besides, this thread
started about compatability between glibc libs. and then wandered into
bitching about redhat's goof. I've already spent too much time on
this, so maybe this rant at http://lwn.net/1999/0211/a/monty.html is
as close as I'll get.
Greg
______________________________________________________________________
Philadelphia Linux Users Group - http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion - http://lists.phillylinux.org/mail/listinfo/plug
|
|