Sorry, but "everyone does it" just doesn't hack it.
Common-sensically it does, but if you say it doesn't I concede.
not what I asked.
It seems to answer your question by implying there's no question regarding
the use or disuse of shared libraries only regarding the strategy (and that
back in 1997). But I can't read beyond the abstract so I can't tell if it
really goes that far. Incidentally, it references some Wirth papers.
you're kind of confusing how the file is created with what ELF wants,
but that's up to you.
Perhaps, I'll try to read up on it.
You need to understand the difference between sections and segments.
From the point of view of the program loader, there is no such thing
as a ..bss.
I believe I understand the difference. The loader may put .bss, .data,
.rodata, and some other data sections around the same place in memory and
decide about the order and relative placement of each. That doesn't change
anything about the binary format, however. Only when the image is being
loaded .bss grows to its true size. On the other hand, .data is more or
less the same in memory or on disk.
But think of it this way: You can have a valid ELF executable that has
no sections. Sections have nothing to do with running the program.
Initialized data has to be placed somewhere in the image, anyway.
So, Wrong for ELF. Sorry. But it's an incredibly common mistake.
I'll try to learn more about it (and probably report back... okay, I won't).
So I guess that acme has more features than vi, since it's extensions
are "any executable"; you guess not.
My claim is you don't actually understand acme.
That's a probable cause but only probable.
Let's leave it at that. Except, uh, who claimed acme was an IDE? Just
wondering. It wasn't me.
Well, leave it at that. By the way, the programmer's do-all is an IDE I
presume.
Finally, thanks for bearing with me and supplying things I didn't know.
--On Wednesday, November 05, 2008 5:25 PM -0800 ron minnich
<[EMAIL PROTECTED]> wrote:
On Wed, Nov 5, 2008 at 4:45 PM, Eris Discordia <[EMAIL PROTECTED]>
wrote:
I know one thing: every major operating system I have ever heard of
leverages shared libraries. Can all those people be wrong? I don't think
so.
I know one thing. Every major operating system in the late 1960s
"knew" that card image files were the way to go. Could all those
people be wrong?
Yes.
Sorry, but "everyone does it" just doesn't hack it.
FWIW, the whole issue of goodness/badness of shared libraries has
never been systematically measured as far as I know -- in terms of
performance cost, overhead, throughput, the usual suspects -- or at
least
I've never seen it done. It would be a lot of work to do it correctly.
Might be interesting.
=
The abstract says this is an overall survey of dynamic linking. I can't
access the full text and I wouldn't understand it even if I could. You
are the CS/CE person. Be the judge, too.
not what I asked.
So the compressed version is only 50% larger than acme. The point being?
That there's a lot of redundancy in the executable image principally
imposed by the binary format.
$ readelf -e /usr/local/bin/vim
Reveals over 170 KB of data only in .data, .rodata, and .bss sections.
$ objdump -s /usr/local/bin/vim
Displays tons of zeroes in all sections except .text. Even RLE could have
considerably reduced the image size.
]
you're kind of confusing how the file is created with what ELF wants,
but that's up to you.
Does the redundant litter cross the network when I have it mounted via
a share and execute the program or not? That was the original
discussion.
I don't know. The size of Emacs executable has as much connection to that
question as I do, but it was _you_ who made the bad Emacs joke.
I.e. You don't know. OK, I'll accept that.
Wrong for ELF.
About ELF:
Defining data elements in the bss section is somewhat different from
defining them in the data section. Instead of declaring specific data
types, you just declare raw segments of memory that are reserved for
whatever purpose you need them for.
[...]
One benefit to declaring data in the bss section is that the data is not
included in the executable program. When data is defined in the data
section, it must be included in the executable program, since it must be
initialized with a specific value. Because the data areas declared in
the bss section are not initialized with program data, the memory areas
are reserved at runtime, and do not have to be included in the final
program.
-- Professional Assembly Programming, Richard Blum, in the context of
using (g)as and ELF
Exactly what I said. I don't want to sound authoritative but when
something is right it is right and there's nothing you or I can do about
it. So: "right for ELF."
I see your confusion, and it is common, and I have made this mistake
too. ELF is like that :-)
And readelf can make it worse.
You need to understand the difference between sections and segments.
From the point of view of the program loader, there is no such thing
as a ..bss.
From the point of view of the linker, there are .bss segments. But
those don't have lots of meaning for a program loader. In fact program
loaders that look at sections are broken.
So you're going to need to go back to the standard, but most people
are: I once worked with code that was created by a big company that
mistakenly parsed the sections, not the segments, of an executable. It
was a mess.
But think of it this way: You can have a valid ELF executable that has
no sections. Sections have nothing to do with running the program.
So, Wrong for ELF. Sorry. But it's an incredibly common mistake.
Example from a simple program for Flat Assembler with Win32 target:
section '.data' data readable writeable
buffer_ptr dd 00h <---- a pointer reserved,
and initialized
buffer db 00FFFFh dup (?) <---- a buffer reserved, but
not initialized
Trust me. I don't care about win32 targets.
Ah! Now we're into feature comparisons! I'm game. How did you get to 1
in 5 and not 1 in 4.8, or 1 in 6?
You know very well that the ratio is an inaccurate measure as the context
suggests. 1 to 5 is like your pinkie to all your fingers. Trying to
"context-switch" and turn a guesstimate into an exact number is only a
diversionary technique you have employed to evade an easily demonstrable
fact. Namely that Acme is a minimal text editor claiming to be an IDE
while Emacs is a behemoth with more features than you could count in a
day, and the following night--not that I believe Emacs is any better
than Acme. Vim leans more towards Emacs.
So I guess that acme has more features than vi, since it's extensions
are "any executable"; you guess not.
My claim is you don't actually understand acme.
Let's leave it at that. Except, uh, who claimed acme was an IDE? Just
wondering. It wasn't me.
ron
