Greetings.
I have a working MIPS cross toolchain with:
binutils-2.15
gcc-3.4.2
glibc-2.3.4
linux-2.6.12
and then decided to work with gcc-4.1.0 out of the cvs head. I am now
getting build problems with glibc-2.3.4 with the first major snafu
being:
../sysdeps/ieee754/dbl-64/s_isinf.c:
Greetings.
While I am getting closer to full toolchain build, GCC-4.1.0 is still
not behaving the way it should. Below is the output that I am running
up against. I attempted to define a stack variable to hold the value
of zero and tried using that instead of the actual value, but nothing
worked. I
zouqiong wrote:
i am surprised about it.
You seem surprised, and I am terrified you are using a compiler that
old. Please go look at:
http://kegel.com/crosstool/
which automatically builds cross toolchains and even still has
scripts to build your ancient (IMHO) combination.
-Steve
Greetings.
I have discovered what appears to be an optimization bug with '-Os'
in GCC-4.1.0 for the MIPS architecture. It appears that functions
which are declared as 'inline' are being ignored and instead turned
into to function calls which is breaking the dynamic linker loader
for uClibc on MIP
Richard Henderson wrote:
Not a bug. The inline marker is merely suggestive. You told
the compiler to optimize for size, and it is doing that.
If you absolutely have to have the function inlined, then you
need to use __attribute__((__always_inline__)).
This makes sense, but I also have a bin
Greetings.
I attempted to search through Bugzilla, but I did not find anything that
matched my query. When using the options '-O0' and '-g' together with GCC-4.1.0,
I get an executable that will segfault. If I use all the other optimizations of
-O1, -O2 or -Os I do not have this problem. I am usi
Eric Christopher wrote:
I've not seen it, but do you see it with, say, those options and the
simulator testsuite? (I don't have one built at the moment or I'd check
myself.)
I assume you mean using the gdb simulator, or what? Sorry for my ignorance.
Otherwise, what's the code look like
Joe Buck wrote:
You might want to first make sure that your program has no memory
access errors. You could try building it for x86 and debugging
with valgrind, to see if that catches anything.
A good idea. I built it for x86. Unfortunately, from the output it
appears that 'clone' is not suppo
The interesting thing to note is that if I edit this and only do one
clone call, things work. As soon as I attempt to do a second clone,
things fall apart when debugging symbols with '-O0 -g' are compiled.
Again, the source link is below. I am going to have to make a note
of this bug and come back
I have spent the last couple of hours groking code and I am coming up
empty on this one. I ran into this problem when trying to build the
'tst-tls10' test program from glibc. This is not a glibc problem, rather
an issue with my library and kernel header files, I think. I have ported
NPTL support f
Jim Wilson wrote:
Those aren't symbolic registers. Those are variable names. Try looking
at the input file tst-tls10.c, and notice that it has variable names a1,
a2, and a3. So somehow, in your output, the variable name a1 got
replaced with the register name $5, which won't work.
*blush
11 matches
Mail list logo
