| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
used to generate the crti.S and crtn.S files. Since we don't use that
anymore, keeping the workaround makes no sense.
Furthermore, in most cases, SAFECFLAGS was not picking up all the
needed flags, causing crti.o and crtn.o to not be built PIC.
Which is very bad. Removing SAFECFLAGS and using CFLAGS fixes
that as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
optimizing.
|
|
|
|
do seem to make noticable speed improvement...
-Erik
|
|
|
|
|
|
|
|
will always win
|
|
Indirectly detected by gmp-4.1.2 self-tests and reported by
"Peter S. Mazinger" <ps.m@gmx.net>.
|
|
are implemented in hardware or via kernel emulation doesn't matter to
the libc code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I think I messed up a little in my latest patch to Erik. Can you try
this on top of CVS(which I think you have already)
Jocke
And later writes:
Hi Erik
I just saw something that might be a problem.
The "delta" variable is signed and
the "delta" calculations, such as delta = PLT_LONGBRANCH_ENTRY_WORDS*4 - (insn_addr-plt_addr+4),
are supposed to be unsigned.
Jocke
|
|
system, rather than being a subordinate lib under a glibc
based system.
-Erik
|
|
not part of uClibc.
|
|
the correct stuff with the correct names, and not install
yet another set of shared libs in the wrong place
-Erik
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Comparing glibc with uClibc makes me think that the delta calculations are
wrong here. Comparing some more I still think there are a
data_words[index] assignments missing. Here is a path that has both the
data_words[index] and the above delta calclations.
This also fixes a terribly obvious bug, also spotted by Joakim, which Erik
introduced when he copied things from the i386 ldso code.
With this patch applied, things now seem to be working perfectly!
|
|
Another little patch fix the configuration for the SH3 targets. The SH3 has
no FPU, but our ldso runs fine on a SH3 target. (I think the
ldso should also run on a SH2 target, so you might want to enable the ldso
for SH2 targets too. But I can't test it, since I have no such a system) :
|
|
Hello Erik,
to compile the new uClibc release for a SH3 we need some little
modifications:
First I fix the crt[in].S files, so we can use them for big endian and
little endian targets.
|
|
Hi again
Back at work. Here is a patch that fixes the 2 errors I found yesterday.
I have excluded the "data_words[index]" part for now.
|
|
|
|
broke a couple of days ago. :-(
|
|
|
|
Oops, found another ppc 8xx bug.
8xx CPUs may need this as well to work:
|
|
|
|
|
|
|
|
|
|
> Very interesting. Do you have any suggestions for how
> we could fix our powerpc shared library loader
Removing those instr. comes with a very big performance
penalty. To flush the dcache you will have read up to 8KB
dummy data and to invalidate the icache you will have to
execute up to 16KB nops. I don't know of any other way from
user space.
hmm, actually I think it will work reliable to perform a
store to the same page(s) as the dcbst/icbi will act on. That
way you will make the DTLB Error happen(if any) prior to the
dcbst/icbi. The worst thing that can happen then is a regular
DTLB Miss and that works for dcbst/icbi.
You will have to lookout for if dcbst/icbi crosses a page
boundary. Then you will have to perform a store to both
pages.
Jocke
# And again later writes:
Hi again
I think I know what the problem is. The
PPC_DCBST;PPC_SYNC;PPC_ICBI;PPC_ISYNC sequence is executed
even if no modification has been done i some cases:
_dl_linux_resolver(), the last else has no store for insns[0].
these is a insns[1] = OPCODE_B(delta - 4) that
does not have a PPC_DCBST.
_dl_do_lazy_reloc(), for R_PPC_NONE there is no store.
for R_PPC_JMP_SLOT there is a
insns[1] = OPCODE_B(delta)that does not
have a PPC_DCBST.
_dl_do_reloc(), for R_PPC_COPY there is no store.
for R_PPC_JMP_SLOT there is a
reloc_addr[1] = OPCODE_B(delta) that does not
have a PPC_DCBST.
_dl_init_got(), I THINK that the
PPC_DCBST(plt);
PPC_DCBST(plt+4);
PPC_DCBST(plt+8);
PPC_SYNC;
PPC_ICBI(plt);
PPC_ICBI(plt+4);
PPC_ICBI(plt+8);
PPC_ISYNC;
is off a bit. The address range does not match the sum
of the plt[] and tramp[] address range.
Jocke
# And then later added the comment:
I think that the tramp[] part should be included in the
PPC_DCBST/PPC_ICBI sequence. Then you have to add entries for
plt+12 and plt+16. If the tramp[] part should be excluded,
then all is well.
Jocke
|
|
showed up while running the latest LTP testsuite.
-Erik
|
|
|
