Linux-Development-Sys Digest #926, Volume #7 Thu, 1 Jun 00 16:13:15 EDT
Contents:
Re: Why compiling "-static" creates HUGE binary??? (Andreas Kahari)
Re: Why compiling "-static" creates HUGE binary??? (Paul D. Smith)
Re: Getting "real" memory address? (Nilesh Patel)
Re: pages from get_free_page swappable? (Nilesh Patel)
Re: Poor performance of IPC on SMP machine ! (Kaz Kylheku)
Re: pages from get_free_page swappable? (Grant Edwards)
Re: Why compiling "-static" creates HUGE binary??? (Robert Krawitz)
Re: pages from get_free_page swappable? (Kaz Kylheku)
Re: Why compiling "-static" creates HUGE binary??? (Matthew Haley)
Re: Why compiling "-static" creates HUGE binary??? (Kaz Kylheku)
Re: Why compiling "-static" creates HUGE binary??? (Dave Platt)
Re: reading from files (Rick Ellis)
Re: GCC EGCS libc libg (Rick Ellis)
Re: Winmodems )Re: Need ideas for university funded project for linux) (Jan Knutar)
Linux Gurus needed (Julian Ruhe)
Re: Winmodems )Re: Need ideas for university funded project for linux) (hac)
----------------------------------------------------------------------------
Crossposted-To: alt.os.linux,linux.dev.c-programming,linux.dev.gcc
Subject: Re: Why compiling "-static" creates HUGE binary???
From: [EMAIL PROTECTED] (Andreas Kahari)
Date: 1 Jun 2000 16:15:01 +0100
In article <b5uZ4.1274$[EMAIL PROTECTED]>,
RM <[EMAIL PROTECTED]> wrote:
>Erik,
>
>Thanks. I did "strip test", and it did reduce the size considerably. The
>striped file is now 205KB. Better, but still....
>For that matter, why does "-static" add so much debug info to the file in
>the first place? GCC has command line options to explicitly control debug
>symbols. This still doesn't make much sense.
>
>Robb.
>
I guess it still has to handle exceptions and a bunch of other
behind-the-scene-stuff things. Do "strings a.out" to see what comes
out. On my Solaris box (on which I use a strange mix of Sun libraries
and GNU tools) I get
libc: warning: libc/libthread interface mismatch: unknown tag value ignored
/dev/pts/
ptem
ldterm
ttcompat
That is, there's code for doing threading, talking to devices and
other stuff.
And by the way, don't ever compile a program into something with the
same name as a shell builtin... Some of my student got really confused
when their 'test' program didn't produce the output they wanted, no
matter how they changed the code... ;-)
/A
--
# Andreas K�h�ri
# All junk e-mail is reported to the
# appropriate authorities, no exceptions.
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Crossposted-To: alt.os.linux,linux.dev.c-programming,linux.dev.gcc
Subject: Re: Why compiling "-static" creates HUGE binary???
Date: 01 Jun 2000 10:31:41 -0400
Reply-To: [EMAIL PROTECTED]
%% "RM" <[EMAIL PROTECTED]> writes:
r> For that matter, why does "-static" add so much debug info to the
r> file in the first place? GCC has command line options to
r> explicitly control debug symbols. This still doesn't make much
r> sense.
The -g command line option to GCC is a _compile_ option, not a _link_
option. IOW, it controls how the .o is created: with or without
debugging. It has no effect at link time, on the libraries you link in,
which are already compiled earlier.
Thus, the strip command is removing the debugging information from the
static libraries you linked in, which were compiled with -g, not your
code, which wasn't.
Also, note that strip removes a few other things besides debugging info
(you won't get much smaller by stripping a non-debug binary, but you
will get a _bit_ smaller).
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: Nilesh Patel <[EMAIL PROTECTED]>
Subject: Re: Getting "real" memory address?
Date: Thu, 01 Jun 2000 09:34:16 -0500
Reply-To: [EMAIL PROTECTED]
Joe Rouvier wrote:
> How do I translate the memory address returned by kmalloc() or
> get_free_page into the "real" hardware memory address?
virt_to_phys ()
>
>
> Also, how can I make sure that this memory doesn't get moved or swapped?
In kernel the memory requested is never swapped.
If you want that a processes memory area should not be swapped than see
mlock ().
However this will not insure 100% that the memory areas which are mmaped ()
wont be swapped. It depends on the system and how much you are mlocking ().
Other areas which contain pages of text segment might get discarded and re
read form the disk.
Nilesh
>
>
> Thanks
------------------------------
From: Nilesh Patel <[EMAIL PROTECTED]>
Subject: Re: pages from get_free_page swappable?
Date: Thu, 01 Jun 2000 09:38:20 -0500
Reply-To: [EMAIL PROTECTED]
It is not swappable.
However the max contiguous real memory you can request is 128k under intel 32
bit.
but if have a DEC Alpha than you can have 256K.
Are you sure you want a contiguous "real memory"
If not than you can use vmalloc () in module to request 256K.
Nilesh
Grant Edwards wrote:
> Are the pages allocated by get_free_page(GFP_KERNEL) swappable?
>
> I need to allocate a large buffer (256K) to hold microcode to
> be download to a device by a kernel module (a daemon reads the
> microcode from disk and passes it to the module via an ioctl()
> during system initialization).
>
> The microcode is required at startup and possibly later if the
> device gets reset. If the buffer is swappable, I'm going to
> allocate it at startup and then just leave it there. If it's
> not swappable, then I'll proabably do it anyway, but I'll feel
> guilty about it.
>
> (And plan on someday implementing a scheme where the module can
> request the data from the daemon each time it is needed.)
>
> --
> Grant Edwards grante Yow! I wonder if I should
> at put myself in ESCROW!!
> visi.com
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Poor performance of IPC on SMP machine !
Reply-To: [EMAIL PROTECTED]
Date: Thu, 01 Jun 2000 15:00:33 GMT
On 28 May 2000 16:14:03 GMT, Boczi <[EMAIL PROTECTED]> wrote:
>
>I'm writiting my thesis, and one part concerns IPC performance on Linux.
>
>I wrote some tests. Classic ping-pong using pipes, message queues and my
>brand new QNX like message passing.
>
>I ran my tests on 2.2.14 kernel with SMP support and the machine was dual
>Pentium 166 MMX with 64 MB of memory. No other processes.
>
>I measured time using gettimeofday at the begining and the end of ping-pong.
>To ensure, that the measurement are worth anything, processes exchangeg data
>10000 times.
>
>The first test I ran with two processors on board.
>Then I turned off the machine, removed one processor and ran the tests again.
>
>And then I was shocked. Results on one-processor machine were ~60% BETTER !!
One contributing factor could be that the one processor works entirely off its
internal cache because it is talking to itself, whereas with two processors,
the messages, and related data, has to travel from one processor to another
through main memory, which is far slower (your sender and receiver will usually
be assigned to different processors when they are both runnable).
Note how the disparity in performance grew wider when you increased the
message size.
Your benchmark is not all that realistic because it spends all its time doing
meaningless communication rather than real work. A well designed application
minimizes its interaction with the kernel to avoid operating system overhead.
The question is whether the IPC performance is sufficient in a realistic
application, not one which spends most of its time executing the IPC code.
>WHY DUAL CPU COMPUTER IS 2 TIMES SLOWER THAN SINGLE CPU ?????
Partly because efficient programming these days is to a large extent an
exercise in caching.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: pages from get_free_page swappable?
Date: Thu, 01 Jun 2000 15:10:26 GMT
In article <[EMAIL PROTECTED]>, Nilesh Patel wrote:
>> I need to allocate a large buffer (256K) to hold microcode to
>> be download to a device by a kernel module (a daemon reads the
>> microcode from disk and passes it to the module via an ioctl()
>> during system initialization).
>>
>> The microcode is required at startup and possibly later if the
>> device gets reset. If the buffer is swappable, I'm going to
>> allocate it at startup and then just leave it there. If it's
>> not swappable, then I'll proabably do it anyway, but I'll feel
>> guilty about it.
>It is not swappable. However the max contiguous real memory you
>can request is 128k under intel 32 bit. but if have a DEC Alpha
>than you can have 256K. Are you sure you want a contiguous
>"real memory" If not than you can use vmalloc () in module to
>request 256K.
No, it isn't contiguous (it's allocated it one page at a time).
What I'm primarily concerned about is that I've got 256K of
non-swappable RAM containing data that is rarely (if ever)
needed. It seems like a waste of resources. If the pages were
swappable, I wouldn't feel so bad.
--
Grant Edwards grante Yow! Loni Anderson's hair
at should be LEGALIZED!!
visi.com
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,linux.dev.c-programming,linux.dev.gcc
Subject: Re: Why compiling "-static" creates HUGE binary???
Date: 01 Jun 2000 11:28:42 -0400
"RMain" <[EMAIL PROTECTED]> writes:
> If I compile the following program (test.c):
>
> int main( void )
> {
> return( 0 );
> }
>
> with gcc as follows:
>
> gcc -m386 -O2 -Wall -fomit-frame-pointer -static -o test test.c
>
> I get a 940KB binary????
What does 'size' say about it?
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for The Gimp Print -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: pages from get_free_page swappable?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 01 Jun 2000 15:33:43 GMT
On Thu, 01 Jun 2000 15:10:26 GMT, Grant Edwards <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, Nilesh Patel wrote:
>
>
>>> I need to allocate a large buffer (256K) to hold microcode to
>>> be download to a device by a kernel module (a daemon reads the
>>> microcode from disk and passes it to the module via an ioctl()
>>> during system initialization).
>>>
>>> The microcode is required at startup and possibly later if the
>>> device gets reset. If the buffer is swappable, I'm going to
>>> allocate it at startup and then just leave it there. If it's
>>> not swappable, then I'll proabably do it anyway, but I'll feel
>>> guilty about it.
>
>>It is not swappable. However the max contiguous real memory you
>>can request is 128k under intel 32 bit. but if have a DEC Alpha
>>than you can have 256K. Are you sure you want a contiguous
>>"real memory" If not than you can use vmalloc () in module to
>>request 256K.
>
>No, it isn't contiguous (it's allocated it one page at a time).
>
>What I'm primarily concerned about is that I've got 256K of
>non-swappable RAM containing data that is rarely (if ever)
>needed. It seems like a waste of resources. If the pages were
>swappable, I wouldn't feel so bad.
What you can do is make a modification to the interface between the daemon and
the module so that the daemon can pass down the data at any time, not just at
startup; the driver just has to notify the daemon whenever this needs to be
done.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Matthew Haley)
Crossposted-To: alt.os.linux,linux.dev.c-programming,linux.dev.gcc
Subject: Re: Why compiling "-static" creates HUGE binary???
Date: Thu, 01 Jun 2000 16:19:53 GMT
On Thu, 1 Jun 2000 08:15:30 -0400,
RMain <[EMAIL PROTECTED]> wrote:
>If I compile the following program (test.c):
>
> int main( void )
> {
> return( 0 );
> }
>
>with gcc as follows:
>
> gcc -m386 -O2 -Wall -fomit-frame-pointer -static -o test test.c
>
>I get a 940KB binary????
On my Mandrake-Linux box the file size is 1.2MB, however, if I run
'strip --strip-debug test' it is reduced to 233k.
$ gcc -m386 -O2 -Wall -fomit-frame-pointer -static -o test test.c
$ ls -lh
total 1.3M
-rwxr-xr-x 1 matt matt 1.2M Jun 1 09:19 test*
-rw-r--r-- 1 matt matt 30 Jun 1 09:17 test.c
$ strip --strip-debug test
$ ls -lh
total 244k
-rwxr-xr-x 1 matt matt 233k Jun 1 09:20 test*
-rw-r--r-- 1 matt matt 30 Jun 1 09:17 test.c
--
Matt Haley <[EMAIL PROTECTED]>
Now showing... Linux-Mandrake 7.02
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: alt.os.linux,linux.dev.c-programming,linux.dev.gcc
Subject: Re: Why compiling "-static" creates HUGE binary???
Reply-To: [EMAIL PROTECTED]
Date: Thu, 01 Jun 2000 16:35:47 GMT
On Thu, 1 Jun 2000 10:09:26 -0400, RM <[EMAIL PROTECTED]> wrote:
>Erik,
>
>Thanks. I did "strip test", and it did reduce the size considerably. The
>striped file is now 205KB. Better, but still....
Although your program does not call any standard functions, it is still linked
to glibc and some run time modules. These modules execute global glibc
initialization code before your program starts. So enough of glibc has to be
added to your static program for this initialization to be able to take place.
The GNU linker does not work on individual functions: if a given object file in
the library archive has a hundred functions, and your program calls just one,
the entire object is linked in.
If you want to make a truly tiny executable, you have to avoid using the run
time modules or glibc. This means that to do anything having to do with the
operating system, you will have to make your own system call stubs.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Dave Platt)
Crossposted-To: alt.os.linux,linux.dev.c-programming,linux.dev.gcc
Subject: Re: Why compiling "-static" creates HUGE binary???
Date: Thu, 01 Jun 2000 17:44:36 GMT
In article <b5uZ4.1274$[EMAIL PROTECTED]>,
RM <[EMAIL PROTECTED]> wrote:
>Thanks. I did "strip test", and it did reduce the size considerably. The
>striped file is now 205KB. Better, but still....
It's not uncommon for a large shared library to be rather
"incestuous"... there are a lot of "cross-module" references within
the library code, and so using even one library routine from within
your program forces much of the library to be loaded.
Ferexample, doing a printf() will end up forcing the loader to bring
in most of the stdio functions... either because these are called
directly or indirectly from within the printf() routine, or because
they happen to be included in the same .c or .s source file as
functions that are called from printf().
It's possible for the developers of libraries to minimize this
size-bloat, by splitting up their source files into smaller files,
each of which contains a set of mutually-interdependent functions, and
by being careful about how and when they make references between
functions in different files/modules. Or (to accomplish a similar
goal) individual functions can be tagged with a compiler directive (a
#pragma or a gcc __attribute__) which causes the complier to place the
functions in different control sections in the object file. Both of
these techniques can (when properly supported by the linker) help
reduce the amount of "optional" code which ends up being loaded
unnecessarily.
Since most programs link with shared libraries, the glibc library
developers haven't tended to emphasize this sort of extreme
modularity. You'll tend to find this sort of segregation more
commonly enforced in libraries and toolkits intended solely for use in
embedded systems, and others which don't support shared libraries.
>For that matter, why does "-static" add so much debug info to the file in
>the first place?
The -static option isn't affecting how much debug information the
compiler is placing in your .o file.
The reason for the difference is that when you link -static, your
image file ends up with the symbol/debug information for your .o file
_and_ for the libc.a unshared library routines. It's the latter which
is bloating your file so much.
--
Dave Platt [EMAIL PROTECTED]
Visit the Jade Warrior home page: http://www.radagast.org/jade-warrior/
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
------------------------------
From: [EMAIL PROTECTED] (Rick Ellis)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: reading from files
Date: 1 Jun 2000 17:47:11 GMT
In article <[EMAIL PROTECTED]>, Philip <[EMAIL PROTECTED]> wrote:
>How do I do this ? I can't find any opensource example and the way I
>would do this is by reading everything char per char and when I find a
>'\t' or a ',' I would write the gathered string to the char .. but I am
>sure that there are better ways ti do this .. so if you know how :)
>please help me out ;o)
man strsep
--
http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: [EMAIL PROTECTED] (Rick Ellis)
Crossposted-To: linux.dev.gcc,linux.dev,comp.os.linux.questions,linux.dev.kernel
Subject: Re: GCC EGCS libc libg
Date: 1 Jun 2000 17:48:38 GMT
In article <[EMAIL PROTECTED]>,
John Gluck <[EMAIL PROTECTED]> wrote:
>1- There is a Pentium optimised compiler that appears to be based on
>gcc. Is it safe for compiling kernels and libs as well as other apps for
>linux???
It is only safe for 2.2 and beyond.
>2- Egcs seems to be the new order for gcc. I can't seem to find any egcs
>source tar files. All I find is gcc. Which are egcs files???
It's back to being called "gcc" now.
--
http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: [EMAIL PROTECTED] (Jan Knutar)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Winmodems )Re: Need ideas for university funded project for linux)
Date: Wed, 31 May 2000 11:22:51 GMT
On Sun, 28 May 2000 08:44:24 GMT, [EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] (Victor Wagner) writes:
>
>Problem is, brilliant PnP devices will try to assign themselves
>unusual IRQs. (Which would be a good idea if not for the fact that
>serial ports didn't work that way 'til PnP.) And Amazing Windows
>will change *every single IRQ in your system* (sometimes) to
>accomodate a new device.
Or in my case where I've jumpered the modem to IRQ2/9, Windows just refuses
to use the modem. I try to edit the resource settings manually, but Windoze
just says "You can't change this resource setting" or something similar.
With Linux it was just setterm /dev/modem IRQ 9..
>Yep. And PCI modems are stupid. (Remind me why we need all that
>bus bandwidth for something that will never pass 56Kb/s?)
My 33.6 modem often passes 128Kb/s when sucking usenet posts. Still, that's
far from the ISA treanfer rate.
--
JK <[EMAIL PROTECTED]>
Any attempt to stretch fuel is guaranteed to increase headwind.
------------------------------
From: Julian Ruhe <[EMAIL PROTECTED]>
Subject: Linux Gurus needed
Date: Thu, 01 Jun 2000 22:10:39 +0200
Hi,
I have a short but, for me, most important question:
Is it possible under Linux to allocate a 64KB sized block of memory,
that is PHYSICALLY (not virtually) aligned on 32KB!!! boundaries and
hanging together in memory (not split by system paging!).
I need a very clear "yes" or "no" and if possible, "how"!
Thank you very much
Julian
p.s. Reply directly to me also. Thank you!
------------------------------
From: hac <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Winmodems )Re: Need ideas for university funded project for linux)
Date: Thu, 01 Jun 2000 20:08:57 GMT
[EMAIL PROTECTED] wrote:
> Problem is, brilliant PnP devices will try to assign themselves
> unusual IRQs. (Which would be a good idea if not for the fact that
> serial ports didn't work that way 'til PnP.) And Amazing Windows
> will change *every single IRQ in your system* (sometimes) to
> accomodate a new device.
>
Windows will change IRQ's only if you permit it. Go into your BIOS
setup, and turn off support for PnP O/S. That's the option that lets
Windows change the assignments. If your BIOS is worth anything (it
may not be), the BIOS should be able to assign the IRQ's correctly,
and Windows (and every other O/S) will use those assignments.
It may be hard to believe, but even as screwed up as Windows does PnP,
there are BIOS's that do an even worse job. That's the only situation
where you should enable "PnP O/S" support. Some BIOS's may have
confusing choices - does enabling "Disable PnP O/S" mean O/S level PnP
is disabled, or did they screw up the label, and 'disable' means
'disable'.
PCI was designed with PnP, and it works, when correctly implemented.
ISA was not designed for PnP, and ISA PnP should be avoided. That's
good enough reason for me to get rid of ISA modems. Yeah, ISA modems
work with Linux, but ISA is a hack job, and its passing should be
celebrated.
--
Howard Christeller Irvine, CA [EMAIL PROTECTED]
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
