linux-gcc-digest Saturday, 11 December 1999 Volume 01 : Number 401
In this issue:
bogue gcc
Re: bogue gcc
binutils 2.9.5.0.19 is released.
[help] newbie question
Re: -fPIC and custom jump tables don't mix
Re: -fPIC and custom jump tables don't mix
Q: native binutils & cross binutils on 1 system.
Re: Q: native binutils & cross binutils on 1 system.
Shared Memory Tutorial
Big variables problem
Re: Shared Memory Tutorial
Re: Big variables problem
Re: Shared Memory Tutorial
Re: Shared Memory Tutorial
Re: Big variables problem
Re: Big variables problem (limited stack size)
Re: Profiling timer not delivered during syscalls?
Re: Big variables problem (limited stack size)
Re: Big variables problem (limited stack size)
Re: Big variables problem (limited stack size)
Re: Big variables problem (limited stack size)
Re: Shared Memory Tutorial
/usr/lib/crt1.o
Re: /usr/lib/crt1.o
Re: /usr/lib/crt1.o
Re: /usr/lib/crt1.o
Re: /usr/lib/crt1.o
Re: /usr/lib/crt1.o
Re: /usr/lib/crt1.o
A GREAT COOKBOOK OFFER
binutils 2.9.5.0.21 is released.
Re: Profiling and threads?
Re: Profiling timer not delivered during syscalls?
gcc 2.95.2 linux compilation problem
Re: gcc 2.95.2 linux compilation problem
Driver for video disp card S3 Trio3D
Re: Driver for video disp card S3 Trio3D
binutils 2.9.5.0.22 is released.
CreativeChildren
See the end of the digest for information on subscribing to the linux-gcc
or linux-gcc-digest mailing lists.
----------------------------------------------------------------------
From: laurent dupont <[EMAIL PROTECTED]>
Date: Thu, 4 Nov 1999 17:32:58 +0100
Subject: bogue gcc
bonjour
j ai lu avec interet votre document sur gcc, mais j ai un probleme:
je travaille avec un redhat 6.0 ( et qui est une mise a jour d une Redhat 5.2)
je n ai pas fait de "bidouilles", ni avant la mise a jour, ni apres
or lorsque je lance gcc j obtiens:
BUG IN DYNAMIC LINKER ld.so: dynamic-link.h: 57: elf_get_dynamic_info: Assertion `!
"bad dynamic tag"' failed!
(et ce, que je tape "gcc" ou que je lance une compilation du noyau!)
Je vous serai reconnaissant de m aider a resoudre ce probleme
merci
A+
Laurent Dupont
------------------------------
From: Scott Bambrough <[EMAIL PROTECTED]>
Date: Thu, 04 Nov 1999 13:31:51 -0500
Subject: Re: bogue gcc
One of the object modules being linked has been compiled without -fPIC.
You need to determine which one and fix it.
use: LD_DEBUG=relocs /lib/ld-linux.so.2 <program name>
This will spit out a lot of information on the relocs it is resolving,
including the symbol it fails on.
Hint: try LD_DEBUG=help for more information.
laurent dupont wrote:
>
> bonjour
>
> j ai lu avec interet votre document sur gcc, mais j ai un probleme:
> je travaille avec un redhat 6.0 ( et qui est une mise a jour d une Redhat 5.2)
> je n ai pas fait de "bidouilles", ni avant la mise a jour, ni apres
> or lorsque je lance gcc j obtiens:
>
> BUG IN DYNAMIC LINKER ld.so: dynamic-link.h: 57: elf_get_dynamic_info: Assertion `!
>"bad dynamic tag"' failed!
>
> (et ce, que je tape "gcc" ou que je lance une compilation du noyau!)
>
> Je vous serai reconnaissant de m aider a resoudre ce probleme
>
> merci
>
> A+
> Laurent Dupont
- --
Scott Bambrough - Software Engineer
REBEL.COM http://www.rebel.com
NetWinder http://www.netwinder.org
------------------------------
From: [EMAIL PROTECTED] (H.J. Lu)
Date: Thu, 4 Nov 1999 11:20:59 -0800 (PST)
Subject: binutils 2.9.5.0.19 is released.
This is the beta release of binutils 2.9.5.0.19 for Linux, which is
based on binutils 1999 1104 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.19 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 ar
melf_linux26} %{!mapcs-26:-m armelf_linux} -p
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.19.tar.bz2. Source code.
2. binutils-2.9.5.0.16-2.9.5.0.19.diff.bz2. Patch against the previous
beta source code.
3. binutils-2.9.5.0.19-1.src.rpm. Source RPM.
4. binutils-2.9.5.0.19-1.i386.rpm. X86 inary RPM for RedHat 6.1.
5. binutils-2.9.5.0.19-1.alpha.rpm. Alpha binary RPM for RedHat 6.1.
There are no gz versions of tar and diff files.
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]
11/04/99
------------------------------
From: hung <[EMAIL PROTECTED]>
Date: Fri, 5 Nov 1999 19:19:16 +1100 (EDT)
Subject: [help] newbie question
hello,
could anyone recommend me a good book on C programming
under Linux ??
Thanks
Hung.
------------------------------
From: Mat Hostetter <[EMAIL PROTECTED]>
Date: 5 Nov 1999 06:37:06 -0500
Subject: Re: -fPIC and custom jump tables don't mix
>>>>> "eric" == Eric W Biederman <ebiederm> writes:
eric> Write valid C and you have a right to complain. As is this is
eric> invalid C, and the compiler can do anything it feels like.
I'm not complaining or pointing fingers. I understand that what I'm
trying to do is not ANSI C, and any C compiler can validly reject this
code. But gcc provides reasonable behavior for many constructs which
are not strictly conforming, which makes it a good tool for writing
low-level system code, such as kernels and (in my case) the target
language for a compiler. The meaning of code which casts an arbitrary
address to a function pointer and then calls it is pretty clear, if
not technically allowed by the standard, so it's reasonable to ask if
it can be made to work in the one circumstance where it fails.
eric> In particular you should write your code more like: typdef void
eric> (*func_ptr)(void); extern func_ptr jump_table[];
eric> jump_table[256]();
That approach would also work, and thank you for suggesting it, but it
means something different. That's a table of function pointers rather
than a sequence of jump instructions. I want my cross-module calls to
compile to simple call instructions, rather than loading a function
pointer out of some table (which is itself at a PC-relative address)
and then calling that.
eric> To me the code just looks silly and bad. If it has a
eric> usefulness you might try asking how to do X. Instead of saying
eric> when I rely on non portable code the compiler doesn't do what I
eric> expect.
Please don't flame me; I'm a C and compiler expert, I know exactly
what I'm doing. Using C as the back end for a compiler occasionally
requires low-level hackery to make it generate the desired code.
gcc+as+ld are very close to doing what I want here, so I'm just asking
if they can be tweaked to handle this case. And even if they can't,
if N+symbol@PLT is always an invalid thing to do then the assembler
should complain rather than silently dropping N.
By the way, I tried to work around this problem by using gcc's `asm
label' extension. I specified an extern function declaration for my
test jump table entry and gave it the asm label "jump_table+2",
etc. hoping the "@PLT" won't appear in the resulting assembly code.
But it appends @PLT anyway (which is not unreasonable...)
- -Mat
------------------------------
From: Ulrich Weigand <[EMAIL PROTECTED]>
Date: Fri, 5 Nov 1999 23:08:47 +0100 (MET)
Subject: Re: -fPIC and custom jump tables don't mix
In linux-gcc you write:
>I'm using C as the back end for a compiler. One of the things this
>compiler generates is a jump table consisting of an array of x86 `jmp'
>instructions. Machine-generated C code calls through this table like
>this:
> extern const char jump_table[];
> typedef void (*func_ptr)(void);
> ....
> ((func_ptr)&jump_table[256])();
>This works fine unless I both optimize and compile with -fPIC. When I
>compile that way (with both the call and the jump table are in the
>same file, FWIW), the above code compiles to this:
> call 256+jump_table@PLT
>That looks plausible, although I don't know what @PLT does.
jump_table@PLT gets resolved by the linker to point to the Procedure
Linkage Table entry for the 'procedure' jump_table. I'm not sure exactly
why the compiler got fooled into thinking there is a PLT entry for
jump_table, as jump_table is not declared as a function ...
As 'jump_table' is really a data symble, you need to look up its absolute
address in the GOT (Global Offset Table) instead, and use this as a jump
target; with inline assembly something like this should work:
__asm__( "movl jump_table@GOT(%%ebx), %%eax\n"
"addl $256, %%eax\n"
"jmp *%%eax\n" );
(This assumes that the %ebx register does indeed contain the GOT address,
as it usually does within gcc generated PIC x86 code ...)
Actually, I'd have assumed that gcc would generate exactly this code
for the code fragment given above, but it appears to get confused.
(Sure, it's undefined behaviour according to the standard, but this
would have been IMHO the logical choice of what to do :-/)
I've experimented using an intermediate variable, like this:
char *ptr = jump_table + 256;
((func_ptr)ptr)();
and *that* does generate exactly the assembly code given above ...
(gcc-2.7.2.3 with -O2 -fPIC)
Of course, the code you are jumping to needs to be aware as well
that it might get loaded at different addresses ... ;-)
- --
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-7688
------------------------------
From: "Bas Mevissen" <[EMAIL PROTECTED]>
Date: Wed, 10 Nov 1999 11:06:56 +0100
Subject: Q: native binutils & cross binutils on 1 system.
Hi,
I want to use both native binutils and cross binutils on one computer.
I use Red Hat 6.1 with binutils-2.9.1.0.23
Problem is, that the cross-build of that binutils package (for arm
development) does overwrite some files.
What I want to have is a way to build "plug-in" packages that can add
cross-dev support packages one at a time, so a solution of supporting 2
fixed targets is not the way I want.
I've seen a solution of moving all duplicate files to another directory and
using a wrapper script for the cross-tools to let them find the proper
files. Is this a good idea? At least you can cleanly add 1 or more targets
Another solution i can think of, is building a version of binutils that
supports all targets in libiberty (and others?) and then building packages
that only add the 'different' files (e.g. <target>-ld etc..)
What's your opinion about this?
Bas.
------------------------------
From: Philip Blundell <[EMAIL PROTECTED]>
Date: Wed, 10 Nov 1999 10:51:41 +0000
Subject: Re: Q: native binutils & cross binutils on 1 system.
>Problem is, that the cross-build of that binutils package (for arm
>development) does overwrite some files.
Which files? This should be no problem.
>Another solution i can think of, is building a version of binutils that
>supports all targets in libiberty (and others?) and then building packages
>that only add the 'different' files (e.g. <target>-ld etc..)
Well, that could work. Configure binutils with --enable-targets=... and just
install gas and ld separately. But it shouldn't be necessary.
p.
------------------------------
From: Rafael Marco de Lucas <[EMAIL PROTECTED]>
Date: Mon, 15 Nov 1999 17:39:43 +0100
Subject: Shared Memory Tutorial
Hello,
can somebody tell me where to find a tutorial about shared memory ?
i want to write a program that reads many data from disk and keeps it
in not swapped memory, after when this program receives a signal it
forks an application that should read an input file and compute something
using the data from the shared memory,,...
if you can send me an example or sugesstion about how to do it
i would thank you a lot,
best cheers,
Rafa
------------------------------
From: Rafael Marco de Lucas <[EMAIL PROTECTED]>
Date: Mon, 15 Nov 1999 17:56:00 +0100
Subject: Big variables problem
Hello, i found that the following program gives an error, why ?
is there any limit in the size of variables ?
main () {
int i;
float jajaja[1000000][300];
i=1;
sleep(1);
}
i tried it compiling with gcc on as linux pc and a digital unix4 machines,
and it only worked using the cc dec compiler,
Rafa
------------------------------
From: [EMAIL PROTECTED]
Date: Mon, 15 Nov 1999 13:08:59 EST
Subject: Re: Shared Memory Tutorial
I'd try info libc, or man -k shared. I bet I could find something that
would serve.
Lawson
>< Microsoft free environment
This mail client runs on Wine. Your mileage may vary.
On Mon, 15 Nov 1999, Rafael Marco de Lucas wrote:
>
> Hello,
> can somebody tell me where to find a tutorial about shared memory ?
> i want to write a program that reads many data from disk and keeps it
> in not swapped memory, after when this program receives a signal it
> forks an application that should read an input file and compute
something
> using the data from the shared memory,,...
> if you can send me an example or sugesstion about how to do it
> i would thank you a lot,
>
> best cheers,
> Rafa
>
>
___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: http://dl.www.juno.com/dynoget/tagj.
------------------------------
From: [EMAIL PROTECTED]
Date: Mon, 15 Nov 1999 13:02:05 EST
Subject: Re: Big variables problem
gcc allocates automatic variables on the stack. Your system
administrator may have limited the stack size to some value [s]he
considers reasonable. You can check with ulimit -s if that is the means
[s]he has used to do so. This is not the limit to the size of one nor
all automatic variables: the stack is also used for other purposes.
If you make a variable static or extern, it will go in the data segment,
which is subject to a different (usually higher) limit (ulimit -d), and
yor program might work. It still won't _do_ anything, however. Or you
could use malloc, shmget, mmap, ... to allocate space for it
dynamically.
There is at least one limit to everything. The ix86 can't address more
than 4gb in any one address space, so it will not have an easy time
working with 1g float values in one variable. Other more stringent
limits may be imposed. Void where proibited.
There is no such thing as a free lunch.
Lawson
>< Microsoft free environment
This mail client runs on Wine. Your mileage may vary.
On Mon, 15 Nov 1999, Rafael Marco de Lucas wrote:
>
> Hello, i found that the following program gives an error, why ?
> is there any limit in the size of variables ?
>
> main () {
> int i;
> float jajaja[1000000][300];
> i=1;
> sleep(1);
> }
>
> i tried it compiling with gcc on as linux pc and a digital unix4
machines,
> and it only worked using the cc dec compiler,
>
> Rafa
>
>
___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: http://dl.www.juno.com/dynoget/tagj.
------------------------------
From: Rafael Marco de Lucas <[EMAIL PROTECTED]>
Date: Tue, 16 Nov 1999 03:21:37 +0100
Subject: Re: Shared Memory Tutorial
Hello,
thank you very much for your answers,
i read the linux programmers guide and it helped me a lot,
i did a first successfull test :-) but i got errors when i tried
to use a bigger size for the shared memory (greater than around 3000000),
what is the origin of the problem ?? is there any limit for the size of
the shared memory ? is possible to change it ?
regards,
Rafa
------------------------------
From: [EMAIL PROTECTED]
Date: Tue, 16 Nov 1999 19:55:05 EST
Subject: Re: Shared Memory Tutorial
Doesn't matter how ridiculously big you set any limit, sooner or later
some pig of a program will bump up against it. Why would you think
there wouldn't be limits?
Why not use perror() to print the error message after the function call
that fails, so you would get a clue?
If you are using shared memory as managed by shmget, shmat, shmctl, and
friends, the limits to that are described in
/usr/[local]/include/asm/shmparam.h, aka
/usr/src/linux/include/asm/shmparam.h
You can change those limits and recompile the kernel, but don't blame me
if you make a kernel that won't boot.
As you will see if you think about it, you cannot share more memory than
there is, either. As a general rule, you will not be able to stand how
slow it runs if you use 3 or more times as much virtual memory as there
is real memory.
Lawson
>< Microsoft free environment
This mail client runs on Wine. Your mileage may vary.
On Tue, 16 Nov 1999, Rafael Marco de Lucas wrote:
>
> Hello,
>
> thank you very much for your answers,
> i read the linux programmers guide and it helped me a lot,
>
> i did a first successfull test :-) but i got errors when i tried
> to use a bigger size for the shared memory (greater than around
3000000),
> what is the origin of the problem ?? is there any limit for the size
of
> the shared memory ? is possible to change it ?
>
> regards,
> Rafa
>
>
___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: http://dl.www.juno.com/dynoget/tagj.
------------------------------
From: [EMAIL PROTECTED]
Date: Wed, 17 Nov 1999 10:08:38 -0600 (CST)
Subject: Re: Big variables problem
It's been rumoured that Rafael Marco de Lucas said:
>
>
> Hello, i found that the following program gives an error, why ?
> is there any limit in the size of variables ?
>
> main () {
> int i;
> float jajaja[1000000][300];
> i=1;
> sleep(1);
> }
>
> i tried it compiling with gcc on as linux pc and a digital unix4 machines,
> and it only worked using the cc dec compiler,
jaja stits on the stack, not the heap.
You need to increase the size of your stack space with teh 'ulimit'
command. It's also possible that the sysadmin set a hard limit
at 8meg or 24 meg. in which case you need the sysadmins help to raise
it.
You can try using malloc to put it on the heap or try
'static float jaja[10000]' to put it in the bss.
- --linas
------------------------------
From: "Dr. Michael Weller" <[EMAIL PROTECTED]>
Date: Wed, 17 Nov 1999 17:19:06 +0100 (MEZ)
Subject: Re: Big variables problem (limited stack size)
On Wed, 17 Nov 1999 [EMAIL PROTECTED] wrote:
> It's been rumoured that Rafael Marco de Lucas said:
> >
> >
> > Hello, i found that the following program gives an error, why ?
> > is there any limit in the size of variables ?
[...]
> jaja stits on the stack, not the heap.
Yes.
> You need to increase the size of your stack space with teh 'ulimit'
> command. It's also possible that the sysadmin set a hard limit
> at 8meg or 24 meg. in which case you need the sysadmins help to raise
> it.
Last time I looked, there was a hard stack limit of 8MB HARDWIRED INTO THE
KERNEL SOURCE.
Now, in my own long-running scientific computations, I use the stack as
much as possible to avoid heap fragmentation when the program is about to
run a month or so allocating and deallocating many temporary vars of
varying types.
Normally my code is not deeply recursively nested though.
As I suspect there are in addition many people with deeply recursive code
too, I always found the 8MB limit quite ridiculous.
As I don't do my computations on linux, I was not yet forced much to raise
the stack limit, so my question(s) [I found no comments about these in the
source]:
Is there any good reason for the 8MB limit? Is it configurable somehow
(in more decent versions, when I looked it even was no #define as far as I
remember) ? Or is this just laziness and noone ever cared to raise the
(hardwired) limit?
AFAIK there was also code missing to lower the preset 8MB stack limit even
more. (might become important if max stacksize becomes something sensible
like 2GB)
Michael.
- --
Michael Weller: [EMAIL PROTECTED], [EMAIL PROTECTED],
or even [EMAIL PROTECTED] If you encounter an eowmob account on
any machine in the net, it's very likely it's me.
------------------------------
From: Karim Yaghmour <[EMAIL PROTECTED]>
Date: Wed, 17 Nov 1999 14:21:51 -0500
Subject: Re: Profiling timer not delivered during syscalls?
About system call latency ... anyone tried the Linux Trace Toolkit?
This will give you exactly how much time is spent in any system
call and what the kernel does during that system call. Total system
overhead is below 1.5% for non-fs intensive systems. This effectively
closes the gprof loop-hoole and reports micro-second accurate system
call / trap / irq information and much more ... Take a look for yourself
LTT's home page:
http://www.info.polymtl.ca/~karym/trace
> calls are not sampled, but I am not sure I like it. High-latency
> system calls can have a big effect on an application's performance.
> If your application is slow because it makes too many slow system
> calls, there does not seem to be any easy way to find that out; the
> results of gprof can even be misleading.
===================================================
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===================================================
------------------------------
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Thu, 18 Nov 1999 11:13:34 +1100
Subject: Re: Big variables problem (limited stack size)
Dr. Michael Weller <[EMAIL PROTECTED]> wrote:
>
> Last time I looked, there was a hard stack limit of 8MB HARDWIRED INTO THE
> KERNEL SOURCE.
Well there certainly isn't such a limit in the copy that I'm looking at right
now.
- --
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
------------------------------
From: [EMAIL PROTECTED]
Date: Wed, 17 Nov 1999 21:36:27 -0600 (CST)
Subject: Re: Big variables problem (limited stack size)
It's been rumoured that Herbert Xu said:
>
> Dr. Michael Weller <[EMAIL PROTECTED]> wrote:
> >
> > Last time I looked, there was a hard stack limit of 8MB HARDWIRED INTO THE
> > KERNEL SOURCE.
>
> Well there certainly isn't such a limit in the copy that I'm looking at right
> now.
The 2.2 kernels should be getting max stack out of the ulimit structures.
- --linas
------------------------------
From: [EMAIL PROTECTED]
Date: Wed, 17 Nov 1999 22:01:04 -0600 (CST)
Subject: Re: Big variables problem (limited stack size)
It's been rumoured that Dr. Michael Weller said:
> Last time I looked, there was a hard stack limit of 8MB HARDWIRED INTO THE
> KERNEL SOURCE.
Only on old kernels.
# /etc/security/limits.conf
#
#Each line describes a limit for a user in the form:
#
#<domain> <type> <item> <value>
#
#Where:
#<domain> can be:
# - an user name
# - a group name, with @group syntax
# - the wildcard *, for default entry
#
#<type> can have the two values:
# - "soft" for enforcing the soft limits
# - "hard" for enforcing hard limits
#
#<item> can be one of the following:
# - core - limits the core file size (KB)
# - data - max data size (KB)
# - fsize - maximum filesize (KB)
# - memlock - max locked-in-memory address space (KB)
# - nofile - max number of open files
# - rss - max resident set size (KB)
# - stack - max stack size (KB)
# - cpu - max CPU time (MIN)
# - nproc - max number of processes
# - as - address space limit
# - maxlogins - max number of logins for this user
#
#<domain> <type> <item> <value>
#
#* soft core 0
#* soft core 0
#* hard rss 10000
#@student hard nproc 20
#@faculty soft nproc 20
#@faculty hard nproc 50
#ftp hard nproc 0
#@student - maxlogins 4
# End of file
[root@shadygrove security]# ulimit -a
core file size (blocks) 1000000
data seg size (kbytes) unlimited
file size (blocks) unlimited
max memory size (kbytes) unlimited
stack size (kbytes) 8192
cpu time (seconds) unlimited
max user processes 256
pipe size (512 bytes) 8
open files 1024
virtual memory (kbytes) 2105343
ulimit: usage: ulimit [-SHacmdstfnpuv] [new limit]
[root@shadygrove security]# ulimit -s 9216
[root@shadygrove security]# ulimit -a
core file size (blocks) 1000000
data seg size (kbytes) unlimited
file size (blocks) unlimited
max memory size (kbytes) unlimited
stack size (kbytes) 9216
cpu time (seconds) unlimited
max user processes 256
pipe size (512 bytes) 8
open files 1024
virtual memory (kbytes) 2106367
------------------------------
From: Wolfram Gloger <[EMAIL PROTECTED]>
Date: 18 Nov 1999 08:42:47 -0000
Subject: Re: Big variables problem (limited stack size)
> It's been rumoured that Dr. Michael Weller said:
> > Last time I looked, there was a hard stack limit of 8MB HARDWIRED INTO THE
> > KERNEL SOURCE.
>
> Only on old kernels.
Care to name which one ?
There was _never_ a `hardwired' stack limit in the Linux kernel, other
than the GB-or-so limit due to address space considerations on 32bit
systems. Many distributions shipped with ulimit -s set to 8MB,
however (quite sensibly, IMHO).
Regards,
Wolfram.
------------------------------
From: Rafael Marco de Lucas <[EMAIL PROTECTED]>
Date: Fri, 19 Nov 1999 02:24:17 +0100
Subject: Re: Shared Memory Tutorial
>Lawson wrote:
>Why not use perror() to print the error message after the function call
>that fails, so you would get a clue?
I did it ---> shmget: Invalid argument
>If you are using shared memory as managed by shmget, shmat, shmctl, and
>friends, the limits to that are described in
>/usr/[local]/include/asm/shmparam.h, aka
ok, i changed it but nothing changed
>You can change those limits and recompile the kernel, but don't blame me
>if you make a kernel that won't boot.
Great !! i did and it worked ! :-) thank you very much for your help
i did a test with 128Mb of shared memory in a pc with redhat with 256Mb(ram)
and i didnt found problems
> if you use 3 or more times as much virtual memory as there is real memory.
.. i will have 1Gb of RAM (4x256Mb simms) and
i will want to create a shared memory segment of size around 800 Mb
>Michael wrote:
>Last time I looked, there was a hard stack limit of 8MB HARDWIRED INTO THE
>KERNEL SOURCE.
> Aaron J. Grier wrote:
>Perhaps what you're looking for is mmap... It is probably slower...
i need it as fast as possible, i will need to read all the shared memory
(arround 800Mb) in few seconds,
so my original problem is solved thanks again for your help,
cheers,
Rafa
------------------------------
From: Ed McMan <[EMAIL PROTECTED]>
Date: Mon, 22 Nov 1999 15:20:22 -0500
Subject: /usr/lib/crt1.o
I've been having a problem recently compilling some programs such as php
that have compiled fine before. The problem is they return an error:
/usr/lib/crt1.o: undefined reference to `main'
Well, I asked a friend, and they said to recompile gcc. So, I
recompiled binutils, got another rpm of gcc. Didn't work. I recompiled
glibc, then I recompiled a version of gcc by myself. Still didn't
work. I have no idea what's wrong...Stuff compiled fine before, but
doesn't now. If anyone knows something about it, I would appreciate
hearing what you had to say. Any help would be appreciated. Thanks.
- --
____________________________________________ |
Email______________________________________| |
__________ \[EMAIL PROTECTED] \ |
Ed McMan \ __________________\ |
__________/______________/ 1 (877) 714 2443 | |
VoiceMail & Fax__________\__________________| |
________________/ |
ICQ 35576339 Website http://i.go.m00.net/ |
________________________________________________|
------------------------------
From: [EMAIL PROTECTED]
Date: Mon, 22 Nov 1999 17:21:34 EST
Subject: Re: /usr/lib/crt1.o
On Mon, 22 Nov 1999, Ed McMan wrote:
> I've been having a problem recently compilling some programs such as
php
> that have compiled fine before. The problem is they return an error:
> /usr/lib/crt1.o: undefined reference to `main'
Compiled fine before _what_?
Your average c program expects to start at main, and it is crt1.o's job
as a startfile to start it there. You could get rid of _that_
particular error by saying, "gcc -nostartfiles" and maybe the errors
that will provoke will tell you something.
> Well, I asked a friend, and they said to recompile gcc. So, I
> recompiled binutils, got another rpm of gcc. Didn't work. I
recompiled
> glibc, then I recompiled a version of gcc by myself. Still didn't
> work. I have no idea what's wrong...Stuff compiled fine before, but
> doesn't now. If anyone knows something about it, I would appreciate
> hearing what you had to say. Any help would be appreciated. Thanks.
> --
> ____________________________________________ |
> Email______________________________________| |
> __________ \[EMAIL PROTECTED] \ |
> Ed McMan \ __________________\ |
> __________/______________/ 1 (877) 714 2443 | |
> VoiceMail & Fax__________\__________________| |
> ________________/ |
> ICQ 35576339 Website http://i.go.m00.net/ |
> ________________________________________________|
>
Lawson
>< Microsoft free environment
This mail client runs on Wine. Your mileage may vary.
___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: http://dl.www.juno.com/dynoget/tagj.
------------------------------
From: Ed McMan <[EMAIL PROTECTED]>
Date: Mon, 22 Nov 1999 19:15:22 -0500
Subject: Re: /usr/lib/crt1.o
> Compiled fine before _what_?
>
> Your average c program expects to start at main, and it is crt1.o's job
> as a startfile to start it there. You could get rid of _that_
> particular error by saying, "gcc -nostartfiles" and maybe the errors
> that will provoke will tell you something.
Thanks for the tip. Below is what it returned. Hm. That would be a
'normal' error for doing that, right?
/usr/powerpc-unknown-linux-gnu/bin/ld; warning: cannont find entry
symbol _start; defaulting to something
- --
____________________________________________ |
Email______________________________________| |
__________ \[EMAIL PROTECTED] \ |
Ed McMan \ __________________\ |
__________/______________/ 1 (877) 714 2443 | |
VoiceMail & Fax__________\__________________| |
________________/ |
ICQ 35576339 Website http://i.go.m00.net/ |
________________________________________________|
------------------------------
From: [EMAIL PROTECTED]
Date: Mon, 22 Nov 1999 19:42:17 EST
Subject: Re: /usr/lib/crt1.o
That would be normal. crt1.o's other job is to define _start
If these are normal c programs, what has happened to main()? You might
scan the source to see if you can find the string "main("; if that's
there, maybe
gcc -c blah.c
nm blah.o |less
(use the less comand / to look for main...)
I repeat, "compiled fine before" - _what_? You, or some program that
ran at your behest or with your implied consent, did something you're
not telling us about :-)
Lawson
>< Microsoft free environment
This mail client runs on Wine. Your mileage may vary.
On Mon, 22 Nov 1999, Ed McMan wrote:
>
> > Compiled fine before _what_?
> >
> > Your average c program expects to start at main, and it is crt1.o's
job
> > as a startfile to start it there. You could get rid of _that_
> > particular error by saying, "gcc -nostartfiles" and maybe the errors
> > that will provoke will tell you something.
> Thanks for the tip. Below is what it returned. Hm. That would be a
> 'normal' error for doing that, right?
> /usr/powerpc-unknown-linux-gnu/bin/ld; warning: cannont find entry
> symbol _start; defaulting to something
>
> --
> ____________________________________________ |
> Email______________________________________| |
> __________ \[EMAIL PROTECTED] \ |
> Ed McMan \ __________________\ |
> __________/______________/ 1 (877) 714 2443 | |
> VoiceMail & Fax__________\__________________| |
> ________________/ |
> ICQ 35576339 Website http://i.go.m00.net/ |
> ________________________________________________|
>
___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: http://dl.www.juno.com/dynoget/tagj.
------------------------------
From: Ed McMan <[EMAIL PROTECTED]>
Date: Mon, 22 Nov 1999 20:12:26 -0500
Subject: Re: /usr/lib/crt1.o
[EMAIL PROTECTED] wrote:
>
> That would be normal. crt1.o's other job is to define _start
> If these are normal c programs, what has happened to main()? You might
> scan the source to see if you can find the string "main("; if that's
> there, maybe
>
> gcc -c blah.c
> nm blah.o |less
> (use the less comand / to look for main...)
>
> I repeat, "compiled fine before" - _what_? You, or some program that
> ran at your behest or with your implied consent, did something you're
> not telling us about :-)
>
> Lawson
Well, the command this happens on is when it's throwing all the binaries
together to make a library. Hm. grep -r "main(" * did not reveal any
binaries with it in. That does make sense seeing it's a library... :)
I don't know when it happened. One day I tried to make a new version of
php, and it didn't work. I went back to compile an old version, still
didn't work.
- --
____________________________________________ |
Email______________________________________| |
__________ \[EMAIL PROTECTED] \ |
Ed McMan \ __________________\ |
__________/______________/ 1 (877) 714 2443 | |
VoiceMail & Fax__________\__________________| |
________________/ |
ICQ 35576339 Website http://i.go.m00.net/ |
________________________________________________|
------------------------------
From: [EMAIL PROTECTED]
Date: Mon, 22 Nov 1999 21:46:16 EST
Subject: Re: /usr/lib/crt1.o
OOPS! A library is not necessarily a normal c program; it is quite
normal for a library not to have a main(), and as you would not normally
run a library as a command, it should have no need to define _start and
no need for crt1.o. I think something has tampered with your Makefile.
Normally, I think you would make a library by giving gcc (or ld) the
option
-shared
which would make appropriate adjustments for other parameters.
You might also want -Wl,-soname,blah.so if you want executables to be
able to reference it by soname.
Often, packages are set up to make a new makefile by running ./configure
if anything in the target system has changed (or when they first meet
the target system), or maybe even autoconf to make a new ./configure
first. Better look back to the README or INSTALL :-)
Sorry, I didn't know php was a library, or I might have saved us a lot
of trouble.
Lawson
>< Microsoft free environment
This mail client runs on Wine. Your mileage may vary.
On Mon, 22 Nov 1999, Ed McMan wrote:
> [EMAIL PROTECTED] wrote:
> >
> > That would be normal. crt1.o's other job is to define _start
> > If these are normal c programs, what has happened to main()? You
might
> > scan the source to see if you can find the string "main("; if that's
> > there, maybe
> >
> > gcc -c blah.c
> > nm blah.o |less
> > (use the less comand / to look for main...)
> >
> > I repeat, "compiled fine before" - _what_? You, or some program that
> > ran at your behest or with your implied consent, did something you're
> > not telling us about :-)
> >
> > Lawson
> Well, the command this happens on is when it's throwing all the
binaries
> together to make a library. Hm. grep -r "main(" * did not reveal any
> binaries with it in. That does make sense seeing it's a library... :)
> I don't know when it happened. One day I tried to make a new version
of
> php, and it didn't work. I went back to compile an old version, still
> didn't work.
> --
> ____________________________________________ |
> Email______________________________________| |
> __________ \[EMAIL PROTECTED] \ |
> Ed McMan \ __________________\ |
> __________/______________/ 1 (877) 714 2443 | |
> VoiceMail & Fax__________\__________________| |
> ________________/ |
> ICQ 35576339 Website http://i.go.m00.net/ |
> ________________________________________________|
>
___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: http://dl.www.juno.com/dynoget/tagj.
------------------------------
From: Ed McMan <[EMAIL PROTECTED]>
Date: Tue, 23 Nov 1999 06:22:57 -0500
Subject: Re: /usr/lib/crt1.o
[EMAIL PROTECTED] wrote:
>
> OOPS! A library is not necessarily a normal c program; it is quite
> normal for a library not to have a main(), and as you would not normally
> run a library as a command, it should have no need to define _start and
> no need for crt1.o. I think something has tampered with your Makefile.
> Normally, I think you would make a library by giving gcc (or ld) the
> option
>
> -shared
>
> which would make appropriate adjustments for other parameters.
>
> You might also want -Wl,-soname,blah.so if you want executables to be
> able to reference it by soname.
>
> Often, packages are set up to make a new makefile by running ./configure
> if anything in the target system has changed (or when they first meet
> the target system), or maybe even autoconf to make a new ./configure
> first. Better look back to the README or INSTALL :-)
>
> Sorry, I didn't know php was a library, or I might have saved us a lot
> of trouble.
>
> Lawson
Oh my. It worked! Thank you *VERY* much! You should've seen me this
morning - I pretty much jumped out of my chair ;)
- --
____________________________________________ |
Email______________________________________| |
__________ \[EMAIL PROTECTED] \ |
Ed McMan \ __________________\ |
__________/______________/ 1 (877) 714 2443 | |
VoiceMail & Fax__________\__________________| |
________________/ |
ICQ 35576339 Website http://i.go.m00.net/ |
________________________________________________|
------------------------------
From: [EMAIL PROTECTED]
Date: Tue, 23 Nov 1999 20:43:00 -0700 (MST)
Subject: A GREAT COOKBOOK OFFER
To You,From Me
Have you ever spend hours long searching for that special holiday recipe,or just
something that'll impress anyone?I know how you feel,so when I got my new job at a
printing factory,i began taking recipes home with me.Now i would like to share all
these recipes with you,for the smallest price possible.I have created text based
cookbooks of all kinds.Over 35 different books to be exact,each containg over 30
different recipes from around the world.I have included the list of books and their
sale prices below........
*The Lowest Price On A Recipe Book EVER!*
ALL ITEMS BELOW ARE FULL BOOKS,NOT SINGLE RECIPES!!!!!
Pies - all books only $8.00 (pie set) !!!
berry - $2.00
chocolate- $2.00
cream - $2.00
fruit- $2.00
Micellanious- $2.00
Holiday Cakes-$3.00
Chocloate Cake-$3.00
Cheesecake- $3.00
Candy-$2.00
Biscotti-$2.00
Chicken-$4.00
Spicy chicken-$4.00
Dips/Spreads-$2.00
Alchoholic Bev. -$4.00
Non-alchoholic bev.-$4.00
Seasonings- $2.00
*Holiday Treats*- $3.00
*Holiday Dressing*-$3.00
Casseroles
meat/meatless-$4.00
tuna/variations-$3.00
Fish and Seafood
crawfish - $2.00
*fish* - $3.00
Shellfish - $2.00
salads - $3.00
FRUIT
blueberry cookbook - $3.00
fruit salads - $2.00
Peaches - $3.00
Assortments - $3.00
MEAT
beef - $5.00
chili - $3.00
lamb - $5.00
pork - $4.00
poultry - $4.00
Snacks
popcorn - $2.00
sandwiches - $2.00
Soups
Chowder - $3.00
Varieties - $3.00
Stew - $3.00
Vegetable,etc
Asparagus - $2.00
Cucumber - $2.00
Micellanious - $2.00
Pickled - $2.00
Potatoes - $2.00
Rice Sides - $2.00
salads - $3.00
Tomatoes - $2.00
Zucchini - $2.00
Vegetarian
Fat Free - $4.00
Include Milk/eggs - $3.00
All orders are in american funds.if you would like to know the price of an item from
outside of the U.S. ,or if have any questions or concerns. send a message to me at:
[EMAIL PROTECTED]
To place an order send cheque or money,along with your order and email address to:
J.Schnitzer
9511-77st
Edmonton Albert
t6c-2m8
An international stamp will be required.
*Also*
If you would like to submit a recipe,send it to [EMAIL PROTECTED] with the
subject as submit recipe
------------------------------
From: [EMAIL PROTECTED] (H.J. Lu)
Date: Wed, 24 Nov 1999 15:51:43 -0800 (PST)
Subject: binutils 2.9.5.0.21 is released.
This is the beta release of binutils 2.9.5.0.21 for Linux, which is
based on binutils 1999 1122 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.21 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 ar
melf_linux26} %{!mapcs-26:-m armelf_linux} -p
Changes from binutils 2.9.5.0.21:
1. Update from binutils 1999 1122. An ia32 gas bug is fixed.
Changes from binutils 2.9.5.0.19:
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.21.tar.bz2. Source code.
2. binutils-2.9.5.0.19-2.9.5.0.21.diff.bz2. Patch against the previous
beta source code.
3. binutils-2.9.5.0.21-1.src.rpm. Source RPM.
4. binutils-2.9.5.0.21-1.i386.rpm. IA32 binary RPM for RedHat 6.1.
5. binutils-2.9.5.0.21-1.alpha.rpm. Alpha binary RPM for RedHat 6.1.
There are no gz versions of tar and diff files.
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]
11/24/99
------------------------------
From: "Martin v. Loewis" <[EMAIL PROTECTED]>
Date: Wed, 1 Dec 1999 00:45:56 +0100
Subject: Re: Profiling and threads?
> Is the call graph data actually correct? That is, are the routines
> which gather that data thread-safe?
No. You'll find the relevant source in glibc 2.1,
gmon/{mcount.c,gmon.c}:_gmonparam, which is a global structure.
> Are profiling timers per-thread? Is it possible for me to enable it
> in the other threads? Would that even work?
This is defined in profil.c, of glibc. These days, gcc only emits the
calls to mcount - implementations of this function are often provided
by the platform. In the specific case of Linux, feel free to ask the
glibc maintainers for their thoughts.
I'd say it is inherently difficult to activate global profiling. What
*might* work is per-thread profiling, and then writing back the
profile data. In any case, the overhead of profiling becomes even more
visible due to the multithreading calls, on each mcount invocation
(which tend to be system calls).
Regards,
Martin
------------------------------
From: "Martin v. Loewis" <[EMAIL PROTECTED]>
Date: Wed, 1 Dec 1999 00:48:41 +0100
Subject: Re: Profiling timer not delivered during syscalls?
> Is this behavior expected? I would have thought that time spent in
> system calls would be pretty important when profiling an application.
Profiling uses the profil(2/3) utility here. It is not a system call
on Linux, so behaviour with regard to system calls might be surprising
(actually, it is a system call, but that does not work). Instead, it
is a C library function implemented with standard system calls (see
glibc sources for details).
If you think this should change, please report that to the Linux
and/or glibc maintainers.
Regards,
Martin
------------------------------
From: Andrew Waegel <[EMAIL PROTECTED]>
Date: Wed, 01 Dec 1999 16:37:37 -0800
Subject: gcc 2.95.2 linux compilation problem
Hello,
I'm hoping someone can help me out with what must be a simple problem.
I recently upgraded to the RedHat 6.1 linux distribution (up from 5.2) and
apparently didn't install GCC from the cd while doing so. As the computer
itself is hard for me to get to, I'm trying to compile and install gcc the
old fashioned way (download the tarball, configure, make, etc.)
When I run gcc's configure script, it complains that I need a working
compiler (to which env var CC must be set). This poses an interesting
problem, since the whole point of this is to build install a compiler!
Under the previous linux version, everthing was fine and I used gcc all the
time, relatively painlessly.
I work with interpreted languages and web services, so all this c stuff is
a little bit voodoo for me, but I must be missing something terribly simple
here.
Any thoughts?
Thanks,
- - Andrew
------------------------------
From: [EMAIL PROTECTED]
Date: Wed, 01 Dec 1999 20:52:34 EST
Subject: Re: gcc 2.95.2 linux compilation problem
I _think_ RedHat 6.0 and 6.1 shipped with egcs as the c compiler, so if
you installed it (rpm -q egcs to check) and glibc-devel, you should be
right to just say CC=egcs ... egcs is roughly the same as gcc-2.95, I
think. If you want to build gcc anyway, egcs should be adequate for the
job. You shouldn't need the stage1/stage2 stuff. Just ./configure make
make install.
gcc is written in c, so (catch 22) you need a c compiler to build it,
either an earlier version of gcc, or an ansi c compiler native to the OS
you are building it for.
Red Hat came down with both feet for glibc with RH 5.0, and I think that
was a good choice. Maybe we'll all learn to know and love egcs in time,
too. Just don't try to compile a 2.0.x kernel with it - or with
gcc-2.95 either, for that matter. Slackware now uses gcc for c, and
egcs for c++.
Lawson
>< Microsoft free environment
This mail client runs on Wine. Your mileage may vary.
On Wed, 1 Dec 1999, Andrew Waegel wrote:
> Hello,
>
> I'm hoping someone can help me out with what must be a simple problem.
>
> I recently upgraded to the RedHat 6.1 linux distribution (up from 5.2)
and
> apparently didn't install GCC from the cd while doing so. As the
computer
> itself is hard for me to get to, I'm trying to compile and install gcc
the
> old fashioned way (download the tarball, configure, make, etc.)
>
> When I run gcc's configure script, it complains that I need a working
> compiler (to which env var CC must be set). This poses an interesting
> problem, since the whole point of this is to build install a compiler!
>
> Under the previous linux version, everthing was fine and I used gcc all
the
> time, relatively painlessly.
>
> I work with interpreted languages and web services, so all this c stuff
is
> a little bit voodoo for me, but I must be missing something terribly
simple
> here.
>
> Any thoughts?
>
> Thanks,
>
> - Andrew
>
___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: http://dl.www.juno.com/dynoget/tagj.
------------------------------
From: Prasanna RN <[EMAIL PROTECTED]>
Date: Thu, 2 Dec 1999 04:39:03 -0800 (PST)
Subject: Driver for video disp card S3 Trio3D
Hello,
Could anyone tell me where to find proper drivers for
my video display card?? Its details are as follows
Chip Type: S3 Trio3D
DAC Type: S3 SDAC
Regards
Prasanna
__________________________________________________
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping: http://shopping.yahoo.com
------------------------------
From: Harald Milz <[EMAIL PROTECTED]>
Date: Thu, 2 Dec 1999 23:41:18 +0100 (CET)
Subject: Re: Driver for video disp card S3 Trio3D
Prasanna RN <[EMAIL PROTECTED]> wrote:
> Hello,
> Could anyone tell me where to find proper drivers for
> my video display card?? Its details are as follows
> Chip Type: S3 Trio3D
> DAC Type: S3 SDAC
XFree86 3.3.5 is your friend. VesaFB runs fine too albeit only w/ 8bpp.
- --
Alas, I am dying beyond my means.
-- Oscar Wilde, as he sipped champagne on his deathbed
------------------------------
From: [EMAIL PROTECTED] (H.J. Lu)
Date: Fri, 10 Dec 1999 08:13:56 -0800 (PST)
Subject: binutils 2.9.5.0.22 is released.
This is the beta release of binutils 2.9.5.0.22 for Linux, which is
based on binutils 1999 1202 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.22 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 ar
melf_linux26} %{!mapcs-26:-m armelf_linux} -p
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.22.tar.bz2. Source code.
2. binutils-2.9.5.0.21-2.9.5.0.22.diff.bz2. Patch against the previous
beta source code.
3. binutils-2.9.5.0.22-1.src.rpm. Source RPM.
4. binutils-2.9.5.0.22-1.i386.rpm. IA32 binary RPM for RedHat 6.1.
5. binutils-2.9.5.0.22-1.alpha.rpm. Alpha binary RPM for RedHat 6.1.
There are no gz versions of tar and diff files.
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]
12/02/99
------------------------------
From: [EMAIL PROTECTED]
Date: Sat, 11 Dec 1999 15:08:28 +0200
Subject: CreativeChildren
Hi,
A recent news item announced the release of "Blood of the Damned", a computer game
which has "a mysterious sect of bloodsuckers and baby snatchers". In another news
item, Brazilian police were said to be investigating whether "Duke Nukem" induced a
medical student to go on a killing spree.
One wonders what these games are teaching youngsters about their attitude towards
people in the real world. I'm NOT thinking of starting a National Campaign Against
Violent Computer Games (how's NACAPAGVICOMGA for an acronym) but is it too much to
hope that if enough parents were to encourage their children to find better uses for
the PC, the tide of violence might be stemmed?
One suitable alternative would be to give youngsters the chance to create their own
sites on the World Wide Web. That is now within everyone's reach. Facilities of high
quality at low cost are provided, together with free Web design tools and Internet
training, at http://www.skyboom.com/amsek/.
If you like the idea, perhaps you would mention it to your friends or, better still,
copy this e-mail to them.
With kind regards,
Pete Fleming
Amsek Electronics
P.S. Please rest assured that there will be no follow-up to this message and you are
not on a mailing list.
------------------------------
End of linux-gcc-digest V1 #401
*******************************
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".
