This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Latest Glibc from CVS has segmentation problems.


Hi Patrick,

"Patrick J. LoPresti" <patl@users.sourceforge.net> writes:
>
> When I change that one line in my boot loader, I do not just select
> the kernel.  I also select ALL OF THE ASSOCIATED MODULES, which
> represent more files than all of glibc's shared libraries combined.
> Those kernel modules all depend on each other, too.  Wow.  How does
> that work?  Coincidence?  Magic?  Some mysterious property unique to
> the kernel?
>
> No, it works because somebody DESIGNED it that way.  The kernel
> installation procedure is what we call a "competent design", to
> distinguish it from, say, the libc installation procedure.

With the risc of furthering this flamewar (I'm not taking any position
here), I'll remind you that modules are statically linked objects,
just like the kernel is.  If they're used, they're also statically in
memory -- they do not move during runtime (unless if you do insmod,
rmmod).

With GNU libc the situation is a lot different -- shared libraries
are in use while you're replacing them (in your scenario), and
they're not completely loaded in memory (if they were, there would be
something to complain about on GNU libc).  Now, kernel and modules
are either completely loaded, or completely outside of memory.

Can you imagine the effect of these "slight" differences? Are you
suggesting that GNU libc be loaded into memory from the startup? And
all the other shared libraries as well?

> Not that it matters.  Obviously it could never be so easy to change
> the C library.  I mean, YOU cannot imagine how it might work, so that
> makes it impossible, right?

I agree that _I_ (not that it matters, since nobody asked me for
opinion) cannot imagine how to make this work without loading complete
library in memory (so runtime doesn't get affected with files changing
in the filesystem), or arranging a messy setup of dual libc
installations on one system (which would take a lot of work, because
shared libraries are not in-memory objects like kernels, you'd need to
do some dancing with symbolic links I think), or modifying init
scripts temporarily to install entire libc before any libc-depending
program is started (but this doesn't allow for keeping two libc setups).

So, with kernel it's as simple as "0x100000 holds the kernel",
"function blah is at 0x104020" etc (real addresses are probably wrong,
don't take that as granted when looking up definition of "blah" :).
Also, kernels are loaded with systems in "fresh" state.  But not libc.

If you want to compare, get yourself enough privileges, and try
overwriting your current running kernel with a new image directly in
memory.

I don't see any options apart from these to "ease" the process of GNU
libc installation, but then again, I rarely compile it myself, and
I'm far from being competent at compiling it at all.

My entire point here is: kernel is easier to replace than a component
like libc in modern GNU systems.  And all that comes out of my
experience as a user, not a developer of either (which means I may be
utterly wrong).

Cheers,
Danilo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]