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
