| Age | Commit message (Collapse) | Author |
|---|
|
chance of actually working
|
|
The patch touches a minor (well, not that minor, but perhaps only
rarely encountered) bug in the powerpc dynamic linker.
The problem is that addi is called in inline assembly, but there is no
restriction on the second argument. In powerpc assembler, if the
second argument to addi is r0, it is taken as the value 0, not the
contents of r0. This happened to me, making the stack pointer 0 on
the invocation on the application.
The patch is against 0.9.22, but there didn't seem to be any changes
to the relevant section in 0.9.23.
|
|
This is just a wild guess, but you could try this to see if it fixes
Richards problem:
|
|
|
|
|
|
|
|
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
|
|
|
|
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!
|
|
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.
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
which should simplify enabling arbitrary architectures.
-Erik
|
|
Remove the ADD_LIBGCC_FUNCTIONS option and do things the right way.
Either we have a shared libgcc available, or the libgcc routines
aren't PIC and don't belong in the shared libc anyway.
|
|
ln.patch:
* Define $(LN) as ln in Rules.mak.
* Change all occurrences of ln into $(LN).
* Change all constructs like (cd path && ln -sf foo/file file)
into $(LN) -sf foo/file path/file. The latter construct is
already used in a number of places so it should not be
an additional compatibility problem.
|
|
rm.patch:
* Define $(RM) as rm -f in Rules.mak and test/Rules.mak
(this is the same definition as gmake uses by default).
* Change all occurrences of rm and rm -f into $(RM).
|
|
install.patch:
* Define $(INSTALL) as install in Rules.mak.
* Change all occurrences of install into $(INSTALL).
* Change all occurrences of mkdir -p into $(INSTALL) -d.
install -d is already used in a number of places so
this should not be an additional compatibility problem.
|
|
already loaded libs, which unsurprisingly would cause dlsym() to
not work at all...
-Erik
|
|
|
|
till I can straighten that out.
|
|
|
|
|
|
_dl_check_if_named_library_is_loaded function
|
|
we would try to re-fixup the lib's relocations with rather
horrible results. So fix that by checking the the dlopened lib
has already had its init functions called, which will never be
the case for newly loaded libs, and skip the rest in that case.
also apply a few minor fixups
|
|
path to the target library
|
|
|
|
|
|
* Assign insead of add when doing relocations.
|
|
|
|
|
|
|
|
versions are insufficient....
|
|
a gcc 2.95 compiler problem on powerpc.
|
|
Hello,
my patch changed the format of the ldso debug output to the same
format as on the i386 systems.
By Stefan
|
|
|
|
|
|
|
|
|
|
|
|
checking for duplicates and returning an alias if an existing lib
is already loaded is still correct for the dlopen case.
|
|
|
|
|
