linux-gcc-digest Tuesday, March 21 2000 Volume 01 : Number 404
In this issue:
Re: glibc 2.1.3
Problems with devpt of chat server
Re: glibc 2.1.3
Floating point traps on x86/glibc 2.1.2
Re: Floating point traps on x86/glibc 2.1.2
Creating libraries...
Re: Creating libraries...
binutils 2.9.5.0.29 is released.
FreeOnlineads.com advertise your product, service, website for FREE.
Unterminated string or character constant
Re: Unterminated string or character constant
How to create a new directory on c/c++?
Re: How to create a new directory on c/c++?
Re: How to create a new directory on c/c++?
stl question?
running multiple files simultaneously
Re: Frame/Linux on FreeBSD?
Re: running multiple files simultaneously
where is ifstream man pages in linux?
Inline assembly for x86?
Re: running multiple files simultaneously
Re: Inline assembly for x86?
RE: running multiple files simultaneously
Re: Inline assembly for x86?
Re: running multiple files simultaneously
Re: Inline assembly for x86?
Re: Inline assembly for x86?
ld error
Re: Inline assembly for x86?
Re: where is ifstream man pages in linux?
Re: where is ifstream man pages in linux?
Binutils 2.9.5.0.31 is released.
Fw: Important - Pleeeeeeeze Read!!!!!]
See the end of the digest for information on subscribing to the linux-gcc
or linux-gcc-digest mailing lists.
----------------------------------------------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Date: 25 Feb 2000 09:03:50 +0100
Subject: Re: glibc 2.1.3
>>>>> Ulrich Drepper writes:
> I've uploaded the 2.1.3 release of glibc to
> ftp://sourceware.cygnus.com/pub/glibc/releases
> There you can find the files
> glibc-2.1.3.tar.bz2 (also .gz)
> glibc-2.1.2-2.1.3.diff.gz
> glibc-linuxthreads-2.1.3.tar.gz
> There is no new crypt add-on since it hasn't changed.
I've uploaded the files now to ftp.gnu.org so that they will appear
soon on your local gnu mirror.
Please note that the crypt add-on is only available from ftp.gwdg.de
(see README or FAQ for details).
Andreas
> This release fixes many bugs in all parts of the library and everybody
> is encouraged to update. Preferably through your distribution
> provider since compiling glibc yourself means taking a risk unless you
> know exactly what you are doing.
> This release should be fully compatible (both directions) with glibc
> 2.1.2. The only part which changed is the format of the files
> containing the locale data. This can be easily fixed by running the
> `localedef' program for the locales which get used on the system (or
> by running `make localedata/install-locales' to update all of them).
- --
Andreas Jaeger
SuSE Labs [EMAIL PROTECTED]
private [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Date: Fri, 25 Feb 2000 19:34:13 +0530 (IST)
Subject: Problems with devpt of chat server
Hi there people
I am trying to develop a chat server kind of a thing with a server and multiple
clients, so that if the client sends a message to the server the server displays it.
Now the thing is that even though this may sound very simple Im a newbie at Linux and
hence am stuck.
The program is giving unexpected results, I am enclosing the code, which is very small
about 200 lines 130 for server and the rest for the client, the program uses sockets
for communication.
Please do try and help and bear with the coding technique cause it is one of a newbie
Thanks in advance
Aditya
Client
#include<stdio.h>
#include<string.h>
#include<unistd.h>
#include<fcntl.h>
#include<sys/socket.h>
#include<sys/types.h>
#include<netinet/in.h>
#include<arpa/inet.h>
#include<errno.h>
#include<stdlib.h>
# define PORT 5556
# define MAX 512
# define SERVERHOST "127.0.0.1"
void write_to_server(int fileid)
{
int nbytes;
char buffer[MAX];
fprintf(stdout,"\nEnter the message");
fscanf(stdin,"%s",buffer);
nbytes=write(fileid,buffer,MAX);
if(nbytes<0) {
perror("Error in write");
exit(EXIT_FAILURE);
}
}
int main(void)
{
int sock;
struct sockaddr_in serv_addr;
char choice;
sock=socket(AF_INET,SOCK_STREAM,0);
if(sock<0) {
perror("Error in write");
exit(EXIT_FAILURE);
}
bzero((char *) &serv_addr, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = inet_addr(SERVERHOST);
serv_addr.sin_port = htons(PORT);
if ((sock = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
perror("client: error in creating socket\n");
exit(EXIT_FAILURE);
}
if (connect(sock, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0) {
perror("error in connecting to server\n");
exit(EXIT_FAILURE);
}
do{
write_to_server(sock);
fprintf(stdout,"\n\tAnmother message?\t");
fscanf(stdin,"%c",&choice);
} while(choice!='n');
close(sock);
exit(EXIT_SUCCESS);
}
/*Client ends here*/
/*Server starts here */
/*This is the server code*/
#include<stdio.h>
#include<string.h>
#include<unistd.h>
#include<fcntl.h>
#include<sys/socket.h>
#include<sys/types.h>
#include<netinet/in.h>
#include<arpa/inet.h>
#include<errno.h>
#include<stdlib.h>
#include<sys/time.h>
#include<fcntl.h>
# define PORT 5556
# define MAX 512
void init_flags(int []);
int read_from_client(int fileid)
{
char buffer[MAX];
int nbytes;
/* fprintf(stdout,"reading from client");*/
nbytes=read(fileid,buffer,MAX);
if(nbytes<0) {
perror("Read error");
exit(EXIT_FAILURE);
}
else if(nbytes==0)
return -1;
else {
fprintf(stdout,"Server got message:%s",buffer);
return 1;
}
}
void init_flags(int flags[])
{
int i;
for(i=0;i<MAX;i++)
flags[i]=0;
}
int main(void)
{
int sock;
int u;
fd_set active_fd_set,read_fd_set,write_fd_set;
int i;
struct sockaddr_in clientname,servername;
size_t size;
int flags[MAX];
struct timeval time;
time.tv_sec =0;
time.tv_usec=0; /*Time set*/
if((sock=socket(AF_INET,SOCK_STREAM,0))<0) {
perror("unable ot make socket :server");
exit(EXIT_FAILURE);
}
bzero((char *)&servername,sizeof(servername));
servername.sin_family=AF_INET;
servername.sin_addr.s_addr=htonl(INADDR_ANY);
servername.sin_port=htons(PORT);
if(bind(sock,(struct sockaddr *)&servername,sizeof(servername))<0) {
perror("error in binding server");
exit(EXIT_FAILURE);
}
if(listen(sock,5)<0) {
perror("Error in listening");
exit(EXIT_FAILURE);
}
FD_ZERO(&active_fd_set);
FD_SET(sock,&active_fd_set);
/* init_flags(flags);*/
while(1) {
read_fd_set=active_fd_set;
if(select(FD_SETSIZE,&read_fd_set,NULL,NULL,&time)<0) {
perror("acceError in select");
exit(EXIT_FAILURE);
}
for(i=0;i<FD_SETSIZE;++i) {
if(FD_ISSET(i,&read_fd_set)) {
if(i==sock /*&&flags[i]==0*/) {
int newsock;
fprintf(stdout,"%d ==%d",sock,i);
size=sizeof(clientname);
fprintf(stdout,"In .....twetwet.");
newsock=accept(sock,(struct sockaddr *)&clientname,&size);
/*flags[i]=1;*/
printf("Adding new client....");
if(newsock<0) {
perror("Error in accept");
exit(EXIT_FAILURE);
}
FD_SET(newsock,&active_fd_set);
}
else {
if(read_from_client(i)) {
/* close(i);*/
FD_CLR(i,&active_fd_set);
fprintf(stdout,"Aditya");
}
}
}
}
}
}
------------------------------
From: Horst von Brand <[EMAIL PROTECTED]>
Date: Fri, 25 Feb 2000 20:05:30 -0300
Subject: Re: glibc 2.1.3
"David S. Miller" <[EMAIL PROTECTED]> said:
> Ugh...
- --- locale/C-ctype.c.~1~ Thu Feb 24 14:48:02 2000
+++ locale/C-ctype.c Thu Feb 24 22:16:42 2000
@@ -376,7 +376,7 @@
{ string: NULL },
- - { string: (const char *) (_nl_C_LC_CTYPE_tolower + 128) }
+ { string: (const char *) (_nl_C_LC_CTYPE_tolower + 128) },
#if BYTE_ORDER == BIG_ENDIAN
{ string: NULL },
#endif
}
};
This is more symmetric, and (IMVHO) less error-prone
- --
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Viña del Mar, Chile +56 32 672616
------------------------------
From: Florian Weimer <[EMAIL PROTECTED]>
Date: 28 Feb 2000 10:47:41 +0100
Subject: Floating point traps on x86/glibc 2.1.2
Isn't the following program supposed to be killed by SIGFPE? It
prints `inf', just as if the call to fesetenv() wasn't there.
#include <fenv.h>
main()
{
fesetenv (FE_NOMASK_ENV);
printf("%g\n", 1.0 / 0.0);
}
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Date: 28 Feb 2000 11:00:15 +0100
Subject: Re: Floating point traps on x86/glibc 2.1.2
>>>>> Florian Weimer writes:
> Isn't the following program supposed to be killed by SIGFPE? It
The compiler is too smart ;-)
> prints `inf', just as if the call to fesetenv() wasn't there.
> #include <fenv.h>
> main()
> {
> fesetenv (FE_NOMASK_ENV);
> printf("%g\n", 1.0 / 0.0);
> }
Try the following program:
#define _GNU_SOURCE 1
#include <fenv.h>
#include <stdio.h>
int
main(void)
{
double one, zero;
one = 1.0;
zero = 0.0;
fesetenv (FE_NOMASK_ENV);
printf("%g\n", one / zero);
}
$ /opt/gcc-2.95/bin/gcc -Wall fenv.c -o fenv
$ ./fenv
Floating point exception
- --
Andreas Jaeger
SuSE Labs [EMAIL PROTECTED]
private [EMAIL PROTECTED]
------------------------------
From: =?iso-8859-1?Q?Jo=E3o?= Borsoi Soares <[EMAIL PROTECTED]>
Date: Wed, 01 Mar 2000 11:38:16 -0300
Subject: Creating libraries...
Hello list. I´m a begginer developer for Linux, and I would like to know
if someone could give me a hand creating libraries. I want to create a
shared library. When programming for Windows I used the _export keyword
before the classes or functions. How should I do when programming for
Linux? And what parameters should I pass to compiler?
Thanks for the help.
Joao.
------------------------------
From: Kurt Wall <[EMAIL PROTECTED]>
Date: Wed, 1 Mar 2000 10:27:53 -0700
Subject: Re: Creating libraries...
João Borsoi Soares spake unto the assembled, saying:
% Hello list. I´m a begginer developer for Linux, and I would like to know
% if someone could give me a hand creating libraries. I want to create a
% shared library. When programming for Windows I used the _export keyword
% before the classes or functions. How should I do when programming for
% Linux? And what parameters should I pass to compiler?
Are you creating static or shared libraries?
To create a static library, compile your code to object form, then
use the 'ar' utility to create an archive. For example:
$ gcc -c libfoo.c -o libfoo.o
$ ar rcs libfoo.a libfoo.o
$ nm libfoo.a
The last command will show you libfoo.a's symbol table.
Creating a shared library is a touch more complicated:
1. Compile to object code using gcc's -fPIC option.
2. Dont' use gcc's -fomit-frame-pointer option.
3. Use gcc's -shared and -soname options.
4. Use gcc's -Wl option to pass arguments to the linker, ld.
5. Link explicity against the C library.
For example:
$ gcc -fPIC -g -c libfoo.c -o libfoo.o
$ gcc -g -shared -Wl,-soname,libfoo.so -o libfoo.so.1.0.0 libfoo.o -lc
This creates a shared library named libfoo.so.1.0.0. Ideally, you
would want to create a couple of symlinks to it, one for the soname,
libfoo.so, and one for the "standard" library file, libfoo.so.1.
Kurt
- --
No group of professionals meets except to conspire against the public at large.
-- Mark Twain
------------------------------
From: "H . J . Lu" <[EMAIL PROTECTED]>
Date: Wed, 1 Mar 2000 11:52:46 -0800
Subject: binutils 2.9.5.0.29 is released.
This is the beta release of binutils 2.9.5.0.29 for Linux, which is
based on binutils 2000 0301 plus various changes. It is purely for
Linux, although it has been tested on Solaris/Sparc and Solaris/x86
from time to time.
I am planning to make the public release soon. Please test it as much
as you can.
Please report any bugs related to binutils 2.9.5.0.29 to [EMAIL PROTECTED]
For arm-linux targets, there are some important differences in behaviour
between these tools and binutils 2.9.1.0.x. The linker emulation name has
changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be
passed with the linker when working with object files (or static libraries)
created using older versions of the assembler. If this flag is omitted the
linker will silently generate bad output when given old input files.
To get the correct behaviour from gcc, amend the *link section of your specs
file as follows:
*link:
%{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared}
%{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker:
-dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m
armelf_linux26} %{!mapcs-26:-m armelf_linux} -p
Changes from binutils 2.9.5.0.27:
1. Update from binutils 2000 0301.
2. A demangler bug is fixed.
3. A better fix for undefined symbols with -Bsymbolic when building
shared library.
Changes from binutils 2.9.5.0.24:
1. Update from binutils 2000 0204.
2. Added -taso to linker on alpha.
3. Fixed a -shared -Bsymbolic bug when PIC is not used.
Changes from binutils 2.9.5.0.22:
1. Update from binutils 2000 0113.
2. A symbol version bug is fixed.
3. A -Bsymbolic bug is fixed.
Changes from binutils 2.9.5.0.21:
1. Update from binutils 1999 1202.
2. Remove a MIPS/ELF change.
3. Enable SOM for HPPA.
Changes from binutils 2.9.5.0.19:
1. Update from binutils 1999 1122. An ia32 gas bug is fixed.
Changes from binutils 2.9.5.0.16:
1. Update from binutils 1999 1104.
2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf.
3. Fix Compaq's demangler support.
Changes from binutils 2.9.5.0.14:
1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21
is fixed.
2. i370 update.
3. The new demangler code. You should use "--style=xxx" to select the
demnangle style instead of "--lang=xxx".
Changes from binutils 2.9.5.0.13:
1. Update from binutils 1999 0925.
2. Fix a -s and linker script bug.
Changes from binutils 2.9.5.0.12:
1. Update from binutils 1999 0922.
2. i370 update.
Changes from binutils 2.9.5.0.11:
1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86
and sparc introduced in the last release.
2. i370 update.
Changes from binutils 2.9.5.0.10:
1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86
and sparc.
2. Remove elf/hppa since it is WIP.
Changes from binutils 2.9.5.0.8:
1. Update from binutils 1999 0831. It allows spaces around '(' and ')'
in x86 FP register names.
Changes from binutils 2.9.5.0.7:
1. Update from binutils 1999 0821.
2. Some MIPS changes.
Changes from binutils 2.9.5.0.6:
1. Update from binutils 1999 0813.
2. i370 update.
Changes from binutils 2.9.5.0.5:
1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed.
Changes from binutils 2.9.5.0.4:
1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed.
2. Remove mips gas patches from binutils 2.9.1.0.25.
Changes from binutils 2.9.5.0.3:
1. Update from binutils 1999 0801.
2. Support for real mode x86 gcc.
Changes from binutils 2.9.4.0.8:
1. Update from binutils 1999 0719. A libc 5 related bug fix.
2. Fix a typo in mips gas.
Changes from binutils 2.9.4.0.7:
1. Update from binutils 1999 0710. A weak symbol bug
http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html
is fixed.
Changes from binutils 2.9.4.0.6:
1. Update from binutils 1999 0626.
Changes from binutils 2.9.4.0.5:
1. Update from binutils 1999 0620.
2. Remove my fwait fix and use the one in cvs.
3. Use "--only-section=section" instead of "--extract-section=section".
for objcopy.
Changes from binutils 2.9.4.0.4:
1. Update from binutils 1999 0612.
2. Remove various temporary fixes of mine since those bugs are fixed
now.
Changes from binutils 2.9.4.0.3:
1. Update from binutils 1999 0611.
2. Remove my ELF/Alpha bfd changes.
3. Use the local symbol copy fix in binutils 1999 0611.
Changes from binutils 2.9.4.0.2:
1. Update from binutils 1999 0607.
2. Remove my Sparc hacks.
3. Fix local symbol copy.
Changes from binutils 2.9.4.0.1:
1. Update from binutils 1999 0606.
2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that
Linux kernel can build.
3. Fix i370 for the new gas.
Changes from binutils 1999 0605:
1. Fix a -Bsymbolic bug for Linux/alpha.
2. Add ELF/i370.
3. Fix 8/16-bit relocations for i386.
4. Add --redefine-sym=old_form=new_form to objcopy.
5. Add "-j section" for objcopy.
6. Fix i386 disassembler for fwait.
7. Fix a Sparc asm bug.
8. Add Ada demangle support.
9. Fix MIPS/ELF bugs.
10. Add some vxworks suppport.
11. Fix a.out assembler.
The file list:
1. binutils-2.9.5.0.29.tar.gz. Source code.
2. binutils-2.9.5.0.27-2.9.5.0.29.diff.gz. Patch against the previous
beta source code.
3. binutils-2.9.5.0.29-1.i386.rpm. IA-32 binary RPM for RedHat 6.1.
There is no separate source rpm. You can do
# rpm -ta binutils-2.9.5.0.29.tar.gz
to create both binary and source rpms.
The primary ftp sites for the beta Linux binutils are:
1. ftp://ftp.valinux.com/pub/support/hjl/binutils
Thanks.
H.J. Lu
[EMAIL PROTECTED]
03/01/2000
------------------------------
From: [EMAIL PROTECTED]
Date: Fri, 3 Mar 2000 16:34:18 GMT
Subject: FreeOnlineads.com advertise your product, service, website for FREE.
Dear Sir/madam
I found your site on the internet and thought you might intrested in
our FREE service.
Initally let me intoduce ourselves to you as www.freeonlineads.com,
we are a FREE internet Classified service. Whether you're looking
to promote, sell, hire or simply let the world know who you are and
what you or your organization, club or community group is doing,
we're sure www.freeadsonle.com will make your experience fast,
easy, fun and absolutly free.
We hope you like the site and find it useful to your business.
Best regards
Sam Lunar
www.freeonlineads.com
------------------------------
From: "Gabor Z. Papp" <[EMAIL PROTECTED]>
Date: Fri, 10 Mar 2000 10:51:06 GMT
Subject: Unterminated string or character constant
When I run more than 2-3 gcc paralell on my i486
Linux 2.3.42
glibc 2.1.2
gcc 2.95.2
I often receive this error:
gcc -Wall -c -s -O3 -fomit-frame-pointer -fstrength-reduce -fPIC -DUNIX -DHAS_POPEN
date2bin.c
In file included from /usr/include/bits/string2.h:1025,
from /usr/include/string.h:346,
from date2bin.c:21:
/usr/include/stdlib.h:664: unterminated string or character constant
/usr/include/stdlib.h:664: possible real start of unterminated constant
/usr/include/stdlib.h:644: unterminated `#if' conditional
make: *** [date2bin.o] Error 1
Issuing a second make solve the problem, gcc compile the
file without problem.
Is this hardware or software problem?
------------------------------
From: "Martin v. Loewis" <[EMAIL PROTECTED]>
Date: Sat, 11 Mar 2000 12:52:54 +0100
Subject: Re: Unterminated string or character constant
> Issuing a second make solve the problem, gcc compile the
> file without problem.
>
> Is this hardware or software problem?
Software is normally deterministic; doing same same thing again and
again should always give the same answer.
That assumption partially relies on the assumption that hardware is
always deterministic. So if you see that doing the same thign a second
time gives a different answer, it could be a hardware problem - gcc
will not, on its own, decide to do something else.
Of course, it might also be a problem of the operating system. For
example, if the file system returns a different file contents the
second time due to a bug in the caching system, the same effect could
occur. If you are using standard, well-tested file systems
(e.g. ext2), this is rather unlikely.
Martin
------------------------------
From: Fenglou Mao <[EMAIL PROTECTED]>
Date: Sun, 12 Mar 2000 11:53:14 +0800 (CST)
Subject: How to create a new directory on c/c++?
How to create a new directory on c/c++?
Thanks!
Sincerely Yours,
FengLou Mao
*******************************
ADD:Mr. FengLou Mao
Institute of Physical Chemistry
Peking University
BeiJing
P.R.China
Tel:86-10-62756833
Fax:86-10-62751725
------------------------------
From: [EMAIL PROTECTED]
Date: Sun, 12 Mar 2000 00:26:51 EST
Subject: Re: How to create a new directory on c/c++?
On Sun, 12 Mar 2000, Fenglou Mao wrote:
> How to create a new directory on c/c++?
> Thanks!
>
> Sincerely Yours,
>
> FengLou Mao
> *******************************
> ADD:Mr. FengLou Mao
> Institute of Physical Chemistry
> Peking University
> BeiJing
> P.R.China
> Tel:86-10-62756833
> Fax:86-10-62751725
>
MKDIR(2) Linux Programmer's Manual MKDIR(2)
NAME
mkdir - create a directory
SYNOPSIS
#include <sys/stat.h>
#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
int mkdir(const char *pathname, mode_t mode);
DESCRIPTION
mkdir attempts to create a directory named pathname.
man 2 mkdir
to see how it ends. I _will_ get you to read the fine manual :-).
If you have pinfo, it does a nice job showing libc.info, which has a
fine description also. info libc will do in a pinch :-)
http://aptiva.caltech.edu/links/rpm/redhat-6.0/RPMS/i386/pinfo-0.5.9-1.i386.rpm
or contrib at any slackware mirror.
Lawson
Installation is performed in the reverse order of removal.
- British Leyland shop manual
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
------------------------------
From: [EMAIL PROTECTED]
Date: Sun, 12 Mar 2000 21:33:47 -0500 (EST)
Subject: Re: How to create a new directory on c/c++?
It's been rumoured that Fenglou Mao said:
>
> How to create a new directory on c/c++?
man 2 mkdir
MKDIR(2) Linux Programmer's Manual MKDIR(2)
NAME
mkdir - create a directory
SYNOPSIS
#include <sys/stat.h>
#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
int mkdir(const char *pathname, mode_t mode);
DESCRIPTION
mkdir attempts to create a directory named pathname.
> Thanks!
>
> Sincerely Yours,
>
> FengLou Mao
> *******************************
> ADD:Mr. FengLou Mao
> Institute of Physical Chemistry
> Peking University
> BeiJing
> P.R.China
> Tel:86-10-62756833
> Fax:86-10-62751725
>
------------------------------
From: Fenglou Mao <[EMAIL PROTECTED]>
Date: Mon, 13 Mar 2000 14:41:29 +0800 (CST)
Subject: stl question?
Dear all,
I use STL "set" to store my data(double type),
I have so many data, I have to out put the data to
a file when the set reach to 1000000 elements,
then I use the function erase() to clear the set,
but it seemed that the program did not release
the memory it used, who can tell me what's the
problem?
Sincerely Yours,
FengLou Mao
*******************************
ADD:Mr. FengLou Mao
Institute of Physical Chemistry
Peking University
BeiJing
P.R.China
Tel:86-10-62756833
Fax:86-10-62751725
------------------------------
From: "Hari Kesavan" <[EMAIL PROTECTED]>
Date: Mon, 13 Mar 2000 07:38:04 PST
Subject: running multiple files simultaneously
Dear all,
I was given a unique,yet seemingly simple problem by my friend & it goes
this way- Create multiple files using C each of which will either read or
write data into a common data file.This data file will be accessed by these
files. Depending on the data read,each of the files should obtain an output
for the next frame.This output should then be stored back in the data file
for the next frame to be processed.
I used 'fread', 'fwrite','fopen', 'fclose' for basic input/output
operations.I created 4 such files & a data file.Each file was compiled on a
different terminal in Linux 6.1.When I executed it I was faced with a
segmentation fault.How can I overcome this?
Yours truly,
Hari
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
------------------------------
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
Date: Mon, 13 Mar 2000 12:41:29 -0800
Subject: Re: Frame/Linux on FreeBSD?
Followup to: <8aiq4a$98d$[EMAIL PROTECTED]>
By author: [EMAIL PROTECTED] (Neil Hoggarth)
In newsgroup: bofh.general
> >
> > That is slightly incomprehensible. After all, there's usually an ELF
> > .interp section pointing out which loader to use, and for Linux
> > executables that's something like (currently) /lib/ld-linux.so.2 -
> > whatever *BSD has there, I imagine it's different.
>
> I suspect that we're seeing elements of the "Cathedral vs. Bazaar"
> culture clash here.
>
> I'm not involved in BSD development (other than as a contented end
> user) but I venture to suggest that "usually" and "something like
> (currently)" are probably not concepts that the FreeBSD architects are
> going to be comfortable basing a solution on.
>
Perhaps, but it's still better that ALWAYS FAIL. However, FreeBSD
isn't the only OS that has these problems. Linux has these problems
in dealing with libc5 vs libc6 binaries, for example, which was the
main reason the libc5->6 jump was a *much* bigger mess than the
libc4->5 one was (there libraries were clearly partitioned by file
format.)
We probably should have something like a .system section that would
unambiguously resolve these kinds of things, even for libraries (which
obviously don't have .interp) and static binaries. Although it's not
going to happen overnight, getting this into binutils now should avoid
yet another mess next time something like this needs to happen.
-hpa
- --
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
------------------------------
From: Kurt Wall <[EMAIL PROTECTED]>
Date: Mon, 13 Mar 2000 18:21:00 -0700
Subject: Re: running multiple files simultaneously
Hari Kesavan spake unto the assembled, saying:
%
% Dear all,
% I was given a unique,yet seemingly simple problem by my friend & it goes
% this way- Create multiple files using C each of which will either read or
% write data into a common data file.This data file will be accessed by these
% files. Depending on the data read,each of the files should obtain an output
% for the next frame.This output should then be stored back in the data file
% for the next frame to be processed.
% I used 'fread', 'fwrite','fopen', 'fclose' for basic input/output
% operations.I created 4 such files & a data file.Each file was compiled on a
% different terminal in Linux 6.1.When I executed it I was faced with a
% segmentation fault.How can I overcome this?
Post the smallest possible compilable program that illustrates the
problem. How can we solve a problem like this without any code?
In the meantime, look for buffer overflows and accesses of uninitialized
pointers.
Kurt
- --
You will lose an important tape file.
------------------------------
From: Fenglou Mao <[EMAIL PROTECTED]>
Date: Tue, 14 Mar 2000 09:42:28 +0800 (CST)
Subject: where is ifstream man pages in linux?
man ifstream no use.
Sincerely Yours,
FengLou Mao
*******************************
ADD:Mr. FengLou Mao
Institute of Physical Chemistry
Peking University
BeiJing
P.R.China
Tel:86-10-62756833
Fax:86-10-62751725
------------------------------
From: [EMAIL PROTECTED]
Date: Sat, 11 Mar 2000 12:36:24 -0800
Subject: Inline assembly for x86?
Hello all,
Does anyone know if gcc supports in-line assembly, and if so, give a
pointer to some documentation?
Thank you,
Don
------------------------------
From: [EMAIL PROTECTED]
Date: Tue, 14 Mar 2000 03:50:40 EST
Subject: Re: running multiple files simultaneously
There is no magic fix for a segment fault. In this case it is caused by
a program error(s), and the way to overcome it is to remove the error(s)
from the program(s). You might find gdb helpful in finding where the
program is erring. I can't tell what you are trying to do, or why you
are trying to do it, but if you expect that a shared file has any
attributes of its own such as file position, you are going to be
disappointed with fread and fwrite. Each program has its own idea of
what is the current position of a file it accesses. Of course, another
program that writes to that file might disrupt that somewhat, but
usually not in any constructive or useful way.
On Mon, 13 Mar 2000, Hari Kesavan wrote:
>
>
> Dear all,
> I was given a unique,yet seemingly simple problem by my friend & it
goes
> this way- Create multiple files using C each of which will either read
or
> write data into a common data file.This data file will be accessed by
these
> files. Depending on the data read,each of the files should obtain an
output
> for the next frame.This output should then be stored back in the data
file
> for the next frame to be processed.
> I used 'fread', 'fwrite','fopen', 'fclose' for basic input/output
> operations.I created 4 such files & a data file.Each file was compiled
on a
> different terminal in Linux 6.1.When I executed it I was faced with a
> segmentation fault.How can I overcome this?
> Yours truly,
> Hari
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
>
Lawson
>< Microsoft free environment
This mail client runs on Wine. Your mileage may vary.
- ---cut here---
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
http://dl.www.juno.com/get/tagh.
------------------------------
From: [EMAIL PROTECTED]
Date: Tue, 14 Mar 2000 03:36:49 EST
Subject: Re: Inline assembly for x86?
Yes, it does. info gcc -> C language extensions -> extended asm
info -f as should be helpful, too: as is the program that is actually
going to assemble your inline assembly coding.
On Sat, 11 Mar 2000 [EMAIL PROTECTED] wrote:
> Hello all,
>
> Does anyone know if gcc supports in-line assembly, and if so, give a
> pointer to some documentation?
>
> Thank you,
>
> Don
>
Lawson
>< Microsoft free environment
This mail client runs on Wine. Your mileage may vary.
- ---cut here---
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
------------------------------
From: =?iso-8859-1?Q?Thomas_B=E4tzler?= <[EMAIL PROTECTED]>
Date: Tue, 14 Mar 2000 09:21:02 +0100
Subject: RE: running multiple files simultaneously
Hi,
you wrote:
> I was given a unique,yet seemingly simple problem by my friend & it goes
>
>
Your friend, the lecturer? :-)
> this way- Create multiple files using C each of which will either read or
> write data into a common data file.This data file will be accessed by
> these
[...]
> segmentation fault.How can I overcome this?
>
W. Richard Stevens, Unix Network Programming. Chapter 3 should have
all you need :-)
HTH,
Thomas
------------------------------
From: Qazi Sami ur Rahman <[EMAIL PROTECTED]>
Date: Tue, 14 Mar 2000 15:42:00 +0500
Subject: Re: Inline assembly for x86?
[EMAIL PROTECTED] wrote:
>
> Hello all,
>
> Does anyone know if gcc supports in-line assembly, and if so, give a
> pointer to some documentation?
>
> Thank you,
>
> Don
Try http://www.rt.e-technik.tu-darmstadt.de/~georg/djgpp/djgpp_asm.html
- --
Qazi Sami ur Rahman <[EMAIL PROTECTED]>
- ---
------------------------------
From: Harald Milz <[EMAIL PROTECTED]>
Date: Tue, 14 Mar 2000 09:26:51 +0100 (CET)
Subject: Re: running multiple files simultaneously
Hari Kesavan <[EMAIL PROTECTED]> wrote:
> I used 'fread', 'fwrite','fopen', 'fclose' for basic input/output
> operations.I created 4 such files & a data file.Each file was compiled on a
> different terminal in Linux 6.1.When I executed it I was faced with a
> segmentation fault.How can I overcome this?
If you want 4 processes (better get used to the right terminology)
to write to the same file, get a clue about locking, and don't use
(buffered) stdio. The segfault is likely unrelated to that issue. And how
do you suppose people to remote debug your programs without showing the
source?
- --
A continuing flow of paper is sufficient to continue the flow of paper.
-- Dyer
------------------------------
From: Qazi Sami ur Rahman <[EMAIL PROTECTED]>
Date: Tue, 14 Mar 2000 15:45:32 +0500
Subject: Re: Inline assembly for x86?
[EMAIL PROTECTED] wrote:
>
> Hello all,
>
> Does anyone know if gcc supports in-line assembly, and if so, give a
> pointer to some documentation?
>
> Thank you,
>
> Don
Sorry my send button is a little quicker. Try this one too:
http://www.castle.net/~avly/djasm.html
Bye.
- --
Qazi Sami ur Rahman <[EMAIL PROTECTED]>
- ---
------------------------------
From: Harald Milz <[EMAIL PROTECTED]>
Date: Tue, 14 Mar 2000 09:36:43 +0100 (CET)
Subject: Re: Inline assembly for x86?
[EMAIL PROTECTED] wrote:
> Does anyone know if gcc supports in-line assembly, and if so, give a
> pointer to some documentation?
The kernel source maybe?
- --
"Wouldn't the sentence 'I want to put a hyphen between the words Fish
and And and And and Chips in my Fish-And-Chips sign' have been clearer
if quotation marks had been placed before Fish, and between Fish and
and, and and and And, and And and and, and and and And, and And and
and, and and and Chips, as well as after Chips?"
------------------------------
From: root <[EMAIL PROTECTED]>
Date: Tue, 14 Mar 2000 17:17:42 -0600
Subject: ld error
On an Alpha LX164, 600mhz, RedHat6.0 with rawhide "enhancements", and
with egcs-1.1.2-30, binutils-2.9.5.0.29, glibc-2.1.3-14, I now get
errors of the form " /usr/bin/ld can"t find __start, defaulting to ..."
when compiling kernels, binutils, Xfree. Same when I downgrade to the
tools on the distribution cd. What is happening, and what can I do to
correct?
Thanks,
Martin Rosenstein
------------------------------
From: "Davide Libenzi" <[EMAIL PROTECTED]>
Date: Tue, 14 Mar 2000 15:46:44 +0100
Subject: Re: Inline assembly for x86?
This is a multi-part message in MIME format.
- ------=_NextPart_000_009B_01BF8DCC.7FF76DF0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
This is a good doc about gcc asm inlining.
Davide.
- --
Feel free, feel Debian !
- ------=_NextPart_000_009B_01BF8DCC.7FF76DF0
Content-Type: text/plain;
name="gcc-asm.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="gcc-asm.txt"
A Brief Tutorial on GCC inline asm (x86 biased)
[EMAIL PROTECTED], 20 April 1998
I am a great fan of GCC's inline asm feature, because there is no need =
to
second-guess or outsmart the compiler. You can tell the compiler what
you are doing and what you expect of it, and it can work with it and
optimize your code.
However, on a convoluted processor like the x86, describing just what is
going on can be quite a complex job. In the interest of a faster kernel
through appropriate usage of this powerful tool, here is an introduction
to its use.
* Extended asm, an introduction.
In a nice clean register-register RISC architecture, accessing an
occasional "foo" instruction is quite simple. You just write:
asm("foo %1,%2,%0" : "=3Dr" (output) : "r" (input1), "r" (input2));
The part before the first colon is very much line the semi-standard
asm() feature that has been in many C compilers since the K&R days.
The string is pasted into the compiler's assembly output at the
current location.
However, GCC is rather cleverer. What will actually appear in the =
output
of "gcc -O -S foo.c" (a file named "foo.s") is:
#APP
foo r17,r5,r9
#NO_APP
The "#APP" and "#NO_APP" parts are instructions to the assembler that
briefly put it into normal operating mode, as opposed to the special
high-speed "compiler output" mode that turns off every feature that
the compiler doesn't use as well as a lot of error-checking. For our
purposes, it's convenient becuase it highlights the part of the code
we're interested in.
Between, you will see that the "%1" and so forth have turned into
registers. This is because GCC replaced "%0", "%1" and "%2"
with registers holding the first three arguments after the colon.
That is, r17 holds input1, r5 holds input2, and r9 holds output.
It's perfectly legal to use more complex expressions like:
asm("foo %1,%2,%0" : "=3Dr" (ptr->vtable[3](a,b,c)->foo.bar[baz]) :
: "r" (gcc(is) + really(damn->cool)), "r" (42));
GCC will treat this just like:
register int t0, t1, t2;
t1 =3D gcc(is) + really(damn->cool);
t2 =3D 42;
asm("foo %1,%2,%0" : "=3Dr" (t0) : "r" (t1), "r" (t2));
ptr->vtable[3](a,b,c)->foo.bar[baz] =3D t0;
The general form of an asm() is
asm( "code" : outputs : inputs : clobbers);
Within the "code", %0 refers to the first argument (usually an
output, unless there are no outputs), %1 to the second, and
so forth. It only goes up to %9. Note that GCC prepends a
tab and appends a newline to the code, so if you want to include
multi-line asm (which is legal) and you want it to look nice
in the asm output, you should separate lines with "\n\t".
(You'll see lots of examples of this in the Linux source.)
It's also legal to use ";" as a separator to put more than one
asm statement on a line.
There are option letters that you can put between the % and the digit
to print the operand specially; more on this later.
Each output or input in the comma-separated list has two parts,
"constraints" and (value). The (value) part is pretty straightforward.
It's an expression. For outputs, it must be an lvalue, i.e. something
that is legal to have on the left side of an assignment.
The constraints are more interesting. All outputs must be marked with
"=3D", which says that this operand is assigned to. I'm not sure why =
this
is necessary, since you also have to divide up outputs and inputs with
the colon, but I'm not inclined to make a fuss about it, since it's easy
to do once you know.
The letters that come after that give permitted operands.
There are more choices than you might think. Some depend on the
processor, but there are a few that are generic.
"r", as example "rm" means a register or memory. "ri" means
a register or an immediate value. "g" is "general"; it can be
anything at all. It's usually equivalent to "rim", but your
processor may have even more options that are included.
"o" is like "m", but "offsettable", meaning that you can add a small
offset to it. On the x86, all memory operands are offsettable, but
some machines don't support indexing and displacement at the same
time, or have something like the 680x0's autoincrement addressing
mode that doesn't support a displacement.
Capital letters starting with "I" are usually assigned to immediate
values in a certain range. For example, a lot of RISC machines
allow either a register or a short immediate value. If our machine
is like the DEC Alpha, and allows a register or a 16-bit immediate,
you could write
asm("foo %1,%2,%0" : "=3Dr" (output) : "r" (input1), "rI" (input2));
and if input2 were, say, 42, the compiler would use an immediate
constant in the instruction.
The x86-specific constraints are defined later.
* A few notes about inputs
An input may be a temporary copy, but it may not be. Unless you
tell GCC that you are going to modify that location (described later
in "equivalence constraints"), you must not alter any inputs.
GCC may, however, elect to place an output in the same register as an
input if it doesn't need the input value any more. You must not make
assumptions either way. If you need to have it one way or the other,
there are ways (described later) to tell GCC what you need.
The rule in GCC's inline asm is, say what you need and then get out
of the optimizer's way.
* x86 assembly code
The GNU tools used in Linux use an AT&T-developed assembly syntax that
is different from the Intel-developed one that you see in a lot of
example code. It's a lot simpler, actually. It doesn't have any of
the DWORD PTR stuff that the Intel syntax requires.
The most significant difference, however, is a major one and easy to get
confused by. While Intel uses "op dest,src", AT&T syntax uses
"op src,dest". DON'T FORGET THIS. If you're used to Intel syntax,
this can take quite a while to get used to.
The easy way to know which flavour of asm syntax you're reading is to
look for all the % synbols. AT&T names the registers %eax, %ebx, etc.
This avoids the need for a kludge like putting _ in front of all the
function and variable names to avoid using perfectly good C names
like esp. It's easy enough to read, but don't forget it when writing.
The other major difference is that the operand size is clear from the
instruction. You don't have just "inc", you have "incb", "incw" and
"incl" to increment 8, 16 or 32 bits. If the size is clear from the
operands, you can just write "inc", (e.g. "inc %eax"), but if it's a
memory operand, rather than writing "inc DWORD PTR foo" you just wrote
"incl foo". "inc foo" is an error; the assembler doesn't try to keep
track of the type of anything. Writing "incl %al" is an error which
the assembler catches.
Immediate values are written with a leading $. Thus, "movl foo,%eax"
copies the contents of memory location foo into %eax. "movl $foo,%eax"
copies the address of foo. "movl 42,%eax" is a fetch from an absolute
address. "movel $42,%eax" is an immediate load.
Addressing modes are written offset(base,index,scale). You may leave
out anything irrelevant. So (%ebx) is legal, as is -44(%ebx,%eax),
which is equivalent to -44(%ebx,%eax,1). Legal scales are 1, 2 4 and 8.
* Equivalence constraints
Sometimes, especially on two-address machines like the x86, you need to
use the same register for output and for input. Although if you look
into the GCC documentation, you'll see a useful-looking "+" constraint
character, this isn't available to inline asm. What you have to do
instead is to use a special constraint like "0":
asm("foo %1,%0" : "=3Dr" (output) : "r" (input1), "0" (input2));
This says that input2 has to go in the same place as the output, so %2
and %0 are the same thing. (Which is why %2 isn't actually mentioned
anywhere.) Note that it is perfectly legal to have different variables
for input and output even though they both use the same register. GCC
will do any necessary copying to temporary registers for you.
* Constraints on the x86
The i386 has *lots* of register classes, designed for anything remotely
useful. Common ones are defined in the "constraints" section of the
GCC manual. Here are the most useful:
g - general effective address
m - memory effective address
r - register
i - immediate value, 0..0xffffffff
n - immediate value known at compile time.
("i" would allow an address known only at link time)
But there are some i386-specific ones described in the =
processor-specific
part of the manual and in more detail in GCC's i386.h:
q - byte-addressible register (eax, ebx, ecx, edx)
A - eax or edx
a, b, c, d, S, D - eax, ebx, ..., esi, edi only
I - immediate 0..31
J - immediate 0..63
K - immediate 255
L - immediate 65535
M - immediate 0..3 (shifts that can be done with lea)
N - immediate 0..255 (one-byte immediate value)
O - immedaite 0..32
There are some more for floating-point registers, but I won't go into
those. The very special cases like "K" are mostly used inside GCC in
alternative code sequences, providing a special-case way to do something
like ANDing with 255.
But something like "I" is useful, for example the x86 rotate left:
asm("roll %1,%0" : "=3Dg" (result) : "cI" (rotate), "0" (input));
(See the section on "x86 assembly syntax" if you wonder why the extra
"l" is on "rol".)
* Advanced constraints
In the GCC manual, constraints and so on are described in most detail
in the section on writing machine descriptions for ports. GCC, not
surprisingly, uses the same constaints mechanism internally to compile
C code. Here's a summary.
=3D has already been discussed, to mark an output. No, I don't know why
it's needed in inline asm, but it's not worth "fixing".
+ is described in the gcc manual, but is not legal in inline
asm. Sorry.
% says that this operand and the next one may be switched at the
compiler's convenience; the arguments are commutative. Many =
operations
(+, *, &, |, ^) have this property, but the options permitted in the
instruction set may not be as general. For example, on a RISC machine
which lets the second operand be an immediate value (in the "I" =
range),
you could specify an add instruction like:
asm("add %1,%2,%0" : "=3Dr" (output) : "%r" (input1), "rI" =
(input2));
, separates a list of alternative constraints. Each input and output
must have the same length list of alternatives, and one element of
the list is chosen. For example, the x86 permits register-memory and
memory-register operations, but not memory-memory. So an add could
be written as:
asm("add %1,%0" : "=3Dr,rm" (output) : "%g,ri" (input1), "0,0" =
(input2));
This says that if the output is a register, input1 may be anything,
but if the output is memory, the input may only be a register or an
immediate value. And input2 must be in the same place as the output,
although you can swap things and place input1 there instead.
If there are multiple options listed and the compiler has no =
preference,
it will choose the first one. Thus, if there's a minor difference
in timing or some such, list the faster one first.
? in one alternative says that an alternative is discouraged. This is
important for compiler-writers who want to encourage the fastest code,
but is getting pretty esoteric for inline asm.
& says that an output operand is written to before the inputs are
read, so this output must not be the same register as any input.
Without this, gcc may place an output and an input in the same =
register
even if not required by a "0" constraint. This is very useful, but
is mentioned here because it's specific to an alternative. Unlike
=3D and %, but like ?, you have to include it with each alternative to
which it applies.
Note that there is no way to encode more complex information, like
"this output may not be in the same place as *that* input, but may
share a ragiater with that *other* input". Each output either may
share a register with any input, or with none.
In inline asm, you usually specify this with every alternative, since
you can't chnage the order of operations depending on the option =
selected.
In GCC's internal code generation, there are provisions for producing
different code depending on the register alternative chosen, but you
can't do that with inline asm.
One place you might use it is when you have the possibility of the
output overlapping with input two, but not input one. E.g.
asm("foo %1,%0; bar %2,%0" : "=3Dr,&r" (out) : "r,r" (in1), "0,r" =
(in2));
This says that either in2 is in the same register as out, or nothing =
is.
However, with more operands, the number of possibilities quickly
mushrooms and GCC doesn't cope gracefully with large numbers of
alternatives.
* Clobbers
Sometimes an instruction knocks out certain specific registers.
The most common example of this is a function call, where the called
function is allowed to do whatever it likes with some registers.
If this is the case, you can list specific registers that get
clobbered by an operation after the inputs. The syntax is
not like constraints, you just provide a comma-separated list of
registers in string form. On the 80x86, they're "ax", "bx",
"si" "di", etc.
There are two special cases for clobbered values. One is "memory",
meaning that this instruction writes to some memory (other than a
listed output) and GCC shouldn't cache memory values in registers across
this asm. An asm memcpy() implementation would need this.
You do *not* need to list "memory" just because outputs are in
memory; gcc understands that.
The second is "cc". It's not necessary on all machines, and I havem't
figured it out for the x86 (I don't think it is), but it's always legal
to specify, and means that the instructions mess up the condition codes.
Note that GCC will not use a clobbered register for inputs or outputs.
GCC 2.7 would let you do it anyway, specifying an input in class
"a" and saying that "ax" is clobbered. GCC 2.8 and egcs are getting
pickeri, and complaining that there are no free registers in class
"a" available. This is not the way to do it. If you corrput an input
register, include a dummy output in the same register, the value of =
which
is never used. E.g.
int dummy;
asm("munge %0" : "=3Dr" (dummy) : "0" (input));
* Temporary registers
People also sometimes erroneously use clobbers for temporary registers.
The right way is to make up a dummy output, and use "=3Dr" or "=3D&r"
depending on the permitted overlap with the inputs. GCC allocates a
register for the dummy value. The difference is that GCC can pick a
convenient register, so it has more flexibility.
* const and volatile
There are two optimization hints that you can give to an asm statement.
asm volatile(...) statements may not be deleted or significantly =
reordered;
the volatile keyword says that they do something magic that the compiler
shouldn't play with too much.
GCC will delete ordinary asm() blocks if the outputs are not used,
and will reorder them slightly to be convenient to where the outputs
are.
(asm blocks with no outputs are assumed to be volatile by default.)
asm const() statements are assumed to produce outputs that depend only =
on
the inputs, and thus can be subject to common subexpression optimization
and can be hoisted out of loops. The most common example of an output
that does *not* depend only on an input is a pointer that is fetched.
*p may change from time to time even if p does not change. Thus, an
asm block that fetches from a pointer should not include a const.
An example of something that is good is a coprocessor instruction to
compute sin(x). If GCC knows that two calls have the same value of
x, it can compute sin(x) only once.
For example, compare:
int foo(int x);
{
int i, y, total;
total =3D 0;
for (i =3D 0; i < 100; i++) {
asm volatile("foo %1,%0" : "=3Dr" (y) : "g" (x));
total +=3D y;
}
return total;
}
then try changing that to "const" after the asm.
The code (on an x86) looks like:
func1:
xorl %ecx,%ecx
pushl %ebx
movl %ecx,%edx
movl 8(%esp),%ebx
.align 4
.L7:
#APP
foo %ebx,%eax
#NO_APP
addl %eax,%ecx
incl %edx
cmpl $99,%edx
jle .L7
movl %ecx,%eax
popl %ebx
ret
which then changes to (in the const case):
func2:
xorl %edx,%edx
#APP
foo 4(%esp),%ecx
#NO_APP
movl %edx,%eax
.align 4
.L13:
addl %ecx,%edx
incl %eax
cmpl $99,%eax
jle .L13
movl %edx,%eax
ret
I'm still not completely thrilled with the code (why put the loop
counter in %eax instead of total, which gets returned), but you can
see how it improves.
* Alternate keywords
__asm__() is a legal alias for asm(), and it is legal (and produces no
warnings) even when in strict-ANSI mode or when warning about =
non-portable
constructs. Otherwise, it is equivalent.
* Output substitutions
Sometimes you want to include a value in an asm statement in an unusual =
way.
For example, you could use the lea instruction to do something hairy =
like
asm("lea %1(%2,%3,1<<%4),%0" : "=3Dr" (out)
: "%i" (in1), "r" (in2), "r" (in3), "M" (logscale));
this looks like a way to generate a legal lea instruction with all the
possible bells and whistles. There's only one problem. When GCC
substitutes the immedaites "in1" and "logscale", it's going to produce
something like:
lea $-44(%ebx,%eax,1<<$2),%ecx
which is a syntax error. The $ on the constants are not useful in
this context. So there are modifier characters. The one
applicable in this context is "c", which means to omit the usual
immediate value information. The correct asm is
asm("lea %c1(%2,%3,1<<%c4),%0" : "=3Dr" (out)
: "%i" (in1), "r" (in2), "r" (in3), "M" (logscale));
which will produce
lea -44(%ebx,%eax,1<<2),%ecx
as desired. There are a few others mentioned in the GCC manual as =
generic:
%c0 substitutes the immediate value %0, but without the immediate =
syntax.
%n0 substitutes like %c0, but the negated value.
%l0 substitutes lile %c0, but with the syntax expected of a jump target.
(This is usually the same as %c0.)
And then there are the x86-specific ones. These are, unfortunately, =
only
listed in the i386.h header file in the GCC source (config/i386/i386.h),
so you havr to dig a bit for them.
%k0 prints the 32-bit form of an operand. %eax, etc.
%w0 prints the 16-bit form of an operand. %ax, etc.
%b0 prints the 8-bit form of an operand. %al, etc.
%h0 prints the high 8-bit form of a register. %ah, etc.
%z0 print opcode suffix coresponding to the operand type, b, w or l.
By default, when %0 prints a register in the form corresponding to
the argument size. E.g. asm("inc %0" : "=3Dr" (out) : "0" (in))
will print as "inc %al", "inc %ax" or "inc %eax" depending
on the type of "out".
For example, byte-swapping on a non-486:
asm("xchg %b0,%h0; roll $16,%0; xchg %b0,%h0" : "=3Dq" (x) : "=3D" =
(x));
This says that x must be in a byte-addressible register and proceeds
to swap the bytes to big-endian form.
It's legal to use the %w and %b forms on objects that aren't
registers, it just makes no difference. Using %b and %h on
non-byte addressible registers tends to make the compiler abort,
so don't do that.
%z is rather cool. For example, consider the following code:
#define xchg(m, in, out) \
asm("xchg%z0 %2,%0" : "=3Dg" (*(m)), "=3Dr" (out) : "1" (in))
int
bar(void *m, int x)
{
xchg((char *)m, (char)x, x);
xchg((short *)m, (short)x, x);
xchg((int *)m, (int)x, x);
return x;
}
This produces, as assembly output,
.globl bar
.type bar,@function
bar:
movl 4(%esp),%eax
movb 8(%esp),%dl
#APP
xchgb %dl,(%eax)
xchgw %dx,(%eax)
xchgl %edx,(%eax)
#NO_APP
movl %edx,%eax
ret
(Re-using x is a way to make sure that nothing got optimized away.)
It's not really needed here because the size of the %2 register
lets you get away with just "xchg", but there are situations
where it's nice to have an operand size.
* Extra % patterns
Some % substitutions don't specify an argument. The most common
one is %%, which comes out as a single %.
The second is %=3D, which generates a unique number for each asm()
block. (Each time it is used if inlined or used in a macro.)
This can be used for temporary labels and so on.
* Examples
Some code that was in include/asm-i386/system.h:
#define _set_tssldt_desc(n,addr,limit,type) \
__asm__ __volatile__ ("movw %3,0(%2)\n\t" \
"movw %%ax,2(%2)\n\t" \
"rorl $16,%%eax\n\t" \
"movb %%al,4(%2)\n\t" \
"movb %4,5(%2)\n\t" \
"movb $0,6(%2)\n\t" \
"movb %%ah,7(%2)\n\t" \
"rorl $16,%%eax" \
: "=3Dm"(*(n)) : "a" (addr), "r"(n), "ri"(limit), "i"(type))
It's obvious that the writer didn't know how to take optimal advantage =
of
this (admittedly complex, but x86 addressing *is* complex) facility.
This could be rewritten to use any register instead of %eax:
#define _set_tssldt_desc(n,addr,limit,type) \
__asm__ __volatile__ ("movw %w3,0(%2)\n\t" \
"movw %w1,2(%2)\n\t" \
"rorl $16,%1\n\t" \
"movb %b1,4(%2)\n\t" \
"movb %4,5(%2)\n\t" \
"movb $0,6(%2)\n\t" \
"movb %h1,7(%2)\n\t" \
"rorl $16,%1" \
: "=3Dm"(*(n)) : "q" (addr), "r"(n), "ri"(limit), "ri"(type))
You notice here that *n is listed as an output, so GCC knows that it's
modified, but actually addressing it is done relative to n as an
input register everywhere because of the need to compute an offset.
The problem is that there is no syntactic way to encode an
offset from a given address. If the address is "40(%eax)" then
an offset of 2 can be made by prepending "2+" to it. But if
the address is "(%eax)" then "2+(%eax)" is not valid.
Tricks like "2+0" fall flat because "040" is taken as octal
and gets translated into 32.
BUT THERE'S NEWS (19 April 1998): gas will actually Do The Right Thing
with "2+(%eax)", just emit a warning. Having seen this, a gas =
maintainer
(Alan Modra) decided to make the warning go away in this case, so in
some near future version you will be able to do it.
With this fix (or putting up with the warning), you could
write the above as:
#define _set_tssldt_desc(n,addr,limit,type) \
__asm__ __volatile__ ("movw %w2,%0\n\t" \
"movw %w1,2+%0\n\t" \
"rorl $16,%1\n\t" \
"movb %b1,4+%0\n\t" \
"movb %3,5+%0\n\t" \
"movb $0,6+%0\n\t" \
"movb %h1,7+%0\n\t" \
"rorl $16,%1" \
: "=3Do"(*(n)) : "q" (addr), "ri"(limit), "i"(type))
The "o" constraint is just like "m", except that it's "offstable";
adding a small value to it leaves a valid address. On the x86,
there is no distinction, so it's not really necessary, but on the
68000, for example, you can't add an offset to a postincrement
addressing mode.
If neither the warning nor waiting is acceptable, a fix is to list each
possible offset as a different output (here we're using the fact that
n is a char *):
__asm__ __volatile__ ("movw %w7,%0\n\t" \
"movw %w6,%1\n\t" \
"rorl $16,%6\n\t" \
"movb %b6,%2\n\t" \
"movb %b8,%3\n\t" \
"movb $0,%4\n\t" \
"movb %h6,%5\n\t" \
"rorl $16,%6" \
: "=3Dm"(*(n)), \
"=3Dm"((n)[2]), \
"=3Dm"((n)[4]), \
"=3Dm"((n)[5]), \
"=3Dm"((n)[6]), \
"=3Dm"((n)[7]) \
: "q" (addr), "g"(limit), "iqm"(type))
Although, as you can see, this gets a bit ugly when you have lots of =
offsets,
but it works just the same.
* Conclusion
I hope this has been of use to some folks. GCC's inline asm features
are really cool becuase you can just do the little bit that you want
and let the compiler optimize the rest.
This has the unfortunate side effect that you have to learn how to
explain to the compiler what's going on. But it's worth it, really!
- ------=_NextPart_000_009B_01BF8DCC.7FF76DF0--
------------------------------
From: "Martin v. Loewis" <[EMAIL PROTECTED]>
Date: Wed, 15 Mar 2000 00:56:28 +0100
Subject: Re: where is ifstream man pages in linux?
> man ifstream no use.
read stroustrup.
Martin
------------------------------
From: "T. Warner" <[EMAIL PROTECTED]>
Date: Wed, 15 Mar 2000 12:49:09 -0500 (EST)
Subject: Re: where is ifstream man pages in linux?
On Wed, 15 Mar 2000, Martin v. Loewis wrote:
> > man ifstream no use.
>
> read stroustrup.
And read his Errata for that book. Martin can attest to my misdirected
questions due to errors in the book. They can be downloaded from his
website.
C++ man pages are a great idea though... ! If only I had more time...
*sigh* Hmm... another colaborative project idea!
>
> Martin
>
- --
Todd Warner
====================================================
mailto:[EMAIL PROTECTED]
====================================================
------------------------------
From: "H . J . Lu" <[EMAIL PROTECTED]>
Date: Tue, 21 Mar 2000 09:01:23 -0800
Subject: Binutils 2.9.5.0.31 is released.
This is the beta release of binutils 2.9.5.0.31 for Linux, which is
based on binutils 2000 0319 plus various changes. It is purely for
Linux, although it has been tested on Solaris/Sparc and Solaris/x86
from time to time.
I am planning to make the public release soon. Please test it as much
as you can.
Please report any bugs related to binutils 2.9.5.0.31 to [EMAIL PROTECTED]
For arm-linux targets, there are some important differences in behaviour
between these tools and binutils 2.9.1.0.x. The linker emulation name has
changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be
passed with the linker when working with object files (or static libraries)
created using older versions of the assembler. If this flag is omitted the
linker will silently generate bad output when given old input files.
To get the correct behaviour from gcc, amend the *link section of your specs
file as follows:
*link:
%{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared}
%{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker:
-dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m
armelf_linux26} %{!mapcs-26:-m armelf_linux} -p
Changes from binutils 2.9.5.0.29:
1. Update from binutils 2000 0319.
2. An ELF/alpha bug is fixed.
Changes from binutils 2.9.5.0.27:
1. Update from binutils 2000 0301.
2. A demangler bug is fixed.
3. A better fix for undefined symbols with -Bsymbolic when building
shared library.
Changes from binutils 2.9.5.0.24:
1. Update from binutils 2000 0204.
2. Added -taso to linker on alpha.
3. Fixed a -shared -Bsymbolic bug when PIC is not used.
Changes from binutils 2.9.5.0.22:
1. Update from binutils 2000 0113.
2. A symbol version bug is fixed.
3. A -Bsymbolic bug is fixed.
Changes from binutils 2.9.5.0.21:
1. Update from binutils 1999 1202.
2. Remove a MIPS/ELF change.
3. Enable SOM for HPPA.
Changes from binutils 2.9.5.0.19:
1. Update from binutils 1999 1122. An ia32 gas bug is fixed.
Changes from binutils 2.9.5.0.16:
1. Update from binutils 1999 1104.
2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf.
3. Fix Compaq's demangler support.
Changes from binutils 2.9.5.0.14:
1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21
is fixed.
2. i370 update.
3. The new demangler code. You should use "--style=xxx" to select the
demnangle style instead of "--lang=xxx".
Changes from binutils 2.9.5.0.13:
1. Update from binutils 1999 0925.
2. Fix a -s and linker script bug.
Changes from binutils 2.9.5.0.12:
1. Update from binutils 1999 0922.
2. i370 update.
Changes from binutils 2.9.5.0.11:
1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86
and sparc introduced in the last release.
2. i370 update.
Changes from binutils 2.9.5.0.10:
1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86
and sparc.
2. Remove elf/hppa since it is WIP.
Changes from binutils 2.9.5.0.8:
1. Update from binutils 1999 0831. It allows spaces around '(' and ')'
in x86 FP register names.
Changes from binutils 2.9.5.0.7:
1. Update from binutils 1999 0821.
2. Some MIPS changes.
Changes from binutils 2.9.5.0.6:
1. Update from binutils 1999 0813.
2. i370 update.
Changes from binutils 2.9.5.0.5:
1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed.
Changes from binutils 2.9.5.0.4:
1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed.
2. Remove mips gas patches from binutils 2.9.1.0.25.
Changes from binutils 2.9.5.0.3:
1. Update from binutils 1999 0801.
2. Support for real mode x86 gcc.
Changes from binutils 2.9.4.0.8:
1. Update from binutils 1999 0719. A libc 5 related bug fix.
2. Fix a typo in mips gas.
Changes from binutils 2.9.4.0.7:
1. Update from binutils 1999 0710. A weak symbol bug
http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html
is fixed.
Changes from binutils 2.9.4.0.6:
1. Update from binutils 1999 0626.
Changes from binutils 2.9.4.0.5:
1. Update from binutils 1999 0620.
2. Remove my fwait fix and use the one in cvs.
3. Use "--only-section=section" instead of "--extract-section=section".
for objcopy.
Changes from binutils 2.9.4.0.4:
1. Update from binutils 1999 0612.
2. Remove various temporary fixes of mine since those bugs are fixed
now.
Changes from binutils 2.9.4.0.3:
1. Update from binutils 1999 0611.
2. Remove my ELF/Alpha bfd changes.
3. Use the local symbol copy fix in binutils 1999 0611.
Changes from binutils 2.9.4.0.2:
1. Update from binutils 1999 0607.
2. Remove my Sparc hacks.
3. Fix local symbol copy.
Changes from binutils 2.9.4.0.1:
1. Update from binutils 1999 0606.
2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that
Linux kernel can build.
3. Fix i370 for the new gas.
Changes from binutils 1999 0605:
1. Fix a -Bsymbolic bug for Linux/alpha.
2. Add ELF/i370.
3. Fix 8/16-bit relocations for i386.
4. Add --redefine-sym=old_form=new_form to objcopy.
5. Add "-j section" for objcopy.
6. Fix i386 disassembler for fwait.
7. Fix a Sparc asm bug.
8. Add Ada demangle support.
9. Fix MIPS/ELF bugs.
10. Add some vxworks suppport.
11. Fix a.out assembler.
The file list:
1. binutils-2.9.5.0.31.tar.gz. Source code.
2. binutils-2.9.5.0.29-2.9.5.0.31.diff.gz. Patch against the previous
beta source code.
3. binutils-2.9.5.0.31-1.i386.rpm. IA-32 binary RPM for RedHat 6.1.
There is no separate source rpm. You can do
# rpm -ta binutils-2.9.5.0.31.tar.gz
to create both binary and source rpms.
The primary ftp sites for the beta Linux binutils are:
1. ftp://ftp.valinux.com/pub/support/hjl/binutils
Thanks.
H.J. Lu
[EMAIL PROTECTED]
03/20/2000
------------------------------
From: "peruzzi" <[EMAIL PROTECTED]>
Date: Tue, 21 Mar 2000 17:07:42 -0800
Subject: Fw: Important - Pleeeeeeeze Read!!!!!]
This is a multi-part message in MIME format.
- ------=_NextPart_000_002E_01BF9357.F7F30540
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
- ----- Original Message -----=20
From: Laurie Youngs=20
To: Zac ; Williard ; Vicki ; That Ugly Guy ; Tanya ; Stover ; Stoney ; =
Steve ; Spo ; Simone ; Shawna ; Shaun ; Sean ; Scotty ; Scott ; Schaefer =
; Sarah ; Ryan ; Rocca ; Rob D. ; Rob ; Rick ; Rich ; Raelee ; Pete ; =
Pat ; Oriana ; No COD's on a PPR ; Nicole ; Nick ; N. Speno ; Morrin ; =
Mom ; Mocko ; Mikey ; Mike W. ; Mel ; Marlie ; Marin ; Luis ; Liz ; Leah =
; Laurie Youngs ; Lauren ; Kirstyn ; Kim ; Kellen ; Kate ; Karen ; Julie =
; Julia ; Josh ; Jordan ; Jodi ; Jo and Jay ; Jessie ; Jeffrey ; Jeff M. =
; Jeff ; Jason R. ; Jamie ; Jackie ; J. Speno ; Harris ; Grillone ; GI =
Jay ; Erik ; Erich ; Eric ; Emmy ; Emily ; Dennis ; Dave ; Cordell ; =
Cooks ; Clark's ; Chris S. ; Chris Everett ; Chris ; Chesa ; Bub ; Bill =
S. ; Bill ; Big Mike ; Becky ; Bart ; Avard ; Aunt Susie ; Aunt Jo ann =
and Uncle Mike ; April ; Anessa ; Andy ; Amy ; Alyson=20
Sent: Tuesday, March 21, 2000 7:24 AM
Subject: Fw: Important - Pleeeeeeeze Read!!!!!]
> >why not try it?
> >I never even read these but thought i would because I received it =
from
> >a friend that never sends these to me.
> >
> -------------------------------------------------------------
>=20
> > >> > This is not a joke. I am forwarding this because the person =
who
> sent it to me is a good friend and does not send me junk. =20
>=20
> Intel and AOL are now discussing a merger which would make them the=20
> largest Internet company and in an effort make sure that AOL remains =
the=20
> most widely used program, Intel and AOL are running an e-mail beta
> test. =20
> When you forward this e-mail to friends, Intel can and will track it =
(if
>=20
> you are a Microsoft Windows user) for a two week time period. For =
every
>=20
> person that you forward this e-mail to, Microsoft will pay you
>=20
> $203.15, for every person that you sent it to that forwards it on,=20
> Microsoft will pay you $156.29 and for every third person that =
receives=20
> it, you will be paid $17.65. Within two weeks,Intel will contact you =
for=20
> your address and then send you a check.
> > >>
> I thought this was a scam myself, but a friend of my good
>=20
> friend's Aunt Patricia, who works at Intel actually got a check for=20
> $4,543.23 by forwarding this e-mail. Try it, what have you got to=20
> lose????
> >>
- ------=_NextPart_000_002E_01BF9357.F7F30540
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3013.2600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV> </DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Laurie=20
Youngs</A> </DIV>
<DIV><B>To:</B> <A href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Zac</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Williard</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Vicki</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>That Ugly Guy</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Tanya</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>Stover</A> =
; <A=20
href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>Stoney</A> =
; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Steve</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Spo</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Simone</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>Shawna</A> ; =
<A=20
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Shaun</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Sean</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Scotty</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Scott</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Schaefer</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Sarah</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Ryan</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Rocca</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>Rob =
D.</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Rob</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Rick</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Rich</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Raelee</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Pete</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Pat</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Oriana</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>No =
COD's on a=20
PPR</A> ; <A href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Nicole</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Nick</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>N. Speno</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Morrin</A>=20
; <A href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>Mom</A> =
; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Mocko</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>Mikey</A> =
; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Mike W.</A>=20
; <A href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>Mel</A> =
; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Marlie</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>Marin</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Luis</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Liz</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Leah</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Laurie=20
Youngs</A> ; <A href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Lauren</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Kirstyn</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Kim</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Kellen</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Kate</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Karen</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Julie</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Julia</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Josh</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Jordan</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Jodi</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Jo and Jay</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Jessie</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Jeffrey</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>Jeff =
M.</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Jeff</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Jason R.</A> ;=20
<A href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Jamie</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>Jackie</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>J. =
Speno</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Harris</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>Grillone</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>GI =
Jay</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Erik</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>Erich</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Eric</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>Emmy</A> =
; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Emily</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Dennis</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Dave</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Cordell</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Cooks</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Clark's</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Chris S.</A> ;=20
<A href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Chris=20
Everett</A> ; <A href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Chris</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Chesa</A> ; <A href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Bub</A> ; <A href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Bill S.</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Bill</A> ;=20
<A href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>Big =
Mike</A> ;=20
<A href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Becky</A>=20
; <A href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Bart</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Avard</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Aunt Susie</A> ; <A =
href=3D"mailto:[EMAIL PROTECTED]"=20
[EMAIL PROTECTED]>Aunt Jo ann and Uncle Mike</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>April</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>Anessa</A> ; =
<A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Andy</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" [EMAIL PROTECTED]>Amy</A> ; <A=20
href=3D"mailto:[EMAIL PROTECTED]" =
[EMAIL PROTECTED]>Alyson</A> </DIV>
<DIV><B>Sent:</B> Tuesday, March 21, 2000 7:24 AM</DIV>
<DIV><B>Subject:</B> Fw: Important - Pleeeeeeeze Read!!!!!]</DIV></DIV>
<DIV><BR></DIV>> >why not try it?<BR>> >I never even read =
these but=20
thought i would because I received it from<BR>> >a friend that =
never sends=20
these to me.<BR>> ><BR>>=20
- -------------------------------------------------------------<BR>>=20
<BR>> > >> > This is not a joke. I am =
forwarding this=20
because the person who<BR>> sent it to me is a good friend and does =
not send=20
me junk. <BR>> <BR>> Intel and AOL are now discussing a =
merger which=20
would make them the <BR>> largest Internet company and in an effort =
make sure=20
that AOL remains the <BR>> most widely used program, Intel and AOL =
are=20
running an e-mail beta<BR>> test. <BR>> When you forward =
this e-mail=20
to friends, Intel can and will track it (if<BR>> <BR>> you are a =
Microsoft=20
Windows user) for a two week time period. For every<BR>> <BR>> =
person that=20
you forward this e-mail to, Microsoft will pay you<BR>> <BR>> =
$203.15, for=20
every person that you sent it to that forwards it on, <BR>> Microsoft =
will=20
pay you $156.29 and for every third person that receives <BR>> =
it, you=20
will be paid $17.65. Within two weeks,Intel will contact you for =
<BR>> your=20
address and then send you a check.<BR>> > >><BR>> I =
thought=20
this was a scam myself, but a friend of my good<BR>> <BR>> =
friend's Aunt=20
Patricia, who works at Intel actually got a check for <BR>> $4,543.23 =
by=20
forwarding this e-mail. Try it, what have you got to <BR>>=20
lose????<BR>> >><BR></BODY></HTML>
- ------=_NextPart_000_002E_01BF9357.F7F30540--
------------------------------
End of linux-gcc-digest V1 #404
*******************************
To subscribe to linux-gcc-digest, send the command:
subscribe linux-gcc-digest
in the body of a message to "[EMAIL PROTECTED]". If you want
to subscribe something other than the account the mail is coming from,
such as a local redistribution list, then append that address to the
"subscribe" command; for example, to subscribe "local-linux-gcc":
subscribe linux-gcc-digest [EMAIL PROTECTED]
A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "linux-gcc-digest"
in the commands above with "linux-gcc".
