| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
to be arch specific to work properly.
|
|
Hi again
All dltest* and test* programs pass for me.
uClibc ld.so resolves according to the OLD weak symbol handling.
I have tried to use the new scheme as well, but that segfaults in all
cases but test3.
|
|
|
|
to make it easier to treat it specially while not bothering the
rest of the code with the same constraints.
|
|
|
|
|
|
|
|
|
|
|
|
-Erik
|
|
|
|
Hello,
the attached patch fixes ldso compilation on sparc-linux (at least with
sparc32 userland). It was made against uClibc 0.9.21, but it's still OK
with 0.9.26.
There were three problems:
- missing __NR_getpid definition
- conflicting prototypes in elfinterp.c
- syntax error (missing semicolon) in ldso.c
With this patch shared libraries and ldso can be built on sparc.
It contains also ldso.c syntax fix for m68k - there was the same
mistake two lines earlier; but I didn't test build on m68k.
|
|
I still don't have a good handle on why and when the different
scope values should be used.
|
|
> Not there yet, but the interfaces are much closer now...
> Heading to bed though, since its 5:30am. :-)
This works, but I discovered something "funny". For all
relocs but COPY you can use scope instead of scope->dyn->symbol_scope
and it is much faster to do that. Search for "Funny" in the patch
to see what I mean. Probably I probably broke something, please let me
know if it works for you too.
I think I am done with ldso now. Has been fun and I hope to
actually use uClibc/busybox soon in a project.
Ohh, there is one thing left, double sized PLT entries, but maybe these
aren't needed in uClibc?
Sweet dreams
Jocke
|
|
_dl_parse_lazy_relocation_information() and _dl_parse_copy_information()
so they are all consistant, allowing for future consolidation.
Trim some trailing whitespace as well.
|
|
|
|
Here is the cleaned up laze reloc patch.
Summary:
- Minor cleanup.
- disable the "if (finaladdr <= 0x01fffffc || finaladdr >= 0xfe000000)"
test since it almost never triggered.
- Optimized the lazy relocs handling.
Would be great if you could commit ASAP.
Jocke
|
|
do both operations in a single pass.
|
|
|
|
Removed R_PPC_NONE and R_PPC_REL24 as these does not seem to be used.
Corrected R_PPC_ADDR32 and R_PPC_JMP_SLOT
|
|
|
|
Hi again
I have done some serious clenup of powerpc/elfinterp.c
- Make it look more like glibc.
- Performance modifictions.
- Fixed a few bugs in _dl_do_reloc(). These seem not to have affected
anything, but this how glibc do it.
Jocke
|
|
_dl_debug_addr prior to checking if it was NULL.
|
|
The current behavior of the powerpc boot1_arch.h seems somewhat broken.
Currently room is made on the stack pointer for the link register, but the link
register is never actually pushed onto it. glibc bears the following comments:
/* Call _dl_start with one parameter pointing at argc */
mr r3,r1
/* (we have to frob the stack pointer a bit to allow room for
_dl_start to save the link register). */
followed by the -16 add to r1. Despite the fact that r1 is modified, the link
register is never actually pushed onto r1, thus the adjustment is completely
superfluous.
There's two possible fixes for this, either saving the link register in the way
that glibc does, or getting rid of the r1 adjustment. As I'm not sure if saving
the link register will actually break the _dl_boot2 callin, both options will
probably want to be played with.
The following bit of inline assembly in the attached patch builds cleanly for
me with gcc 3.3 on darwin, but I'm not able to test it any further beyond that.
|
|
> Is there anything I can do/provide that would assist in the solving of
> this problem on PowerPC? I'm still concerned about my lack of flash space...
Try this path. It fixes the recent ldso problems for me on my mpc860 board.
You should be able to use ldso without the dcbx patch to the kernel now.
Please report back.
Jocke
|
|
avoid problems 'hidden symbol' problems. Also handle -lfloat for the
soft-float arm case.
|
|
inclusion will cause the loader to crash when jumping to the application.
The reason is due to the START macro having a "leave" instruction included
to fixup the stack before starting the app.
|
|
|
|
Hello Erik!
I have made some cosmetical changes to the files, removed the added
SCRT=-fPIC option from building the crt0.S file (but it is a requirement
to build them with -fPIC), and changed some comments. I have left the
ldso.c patch with PIE_SUPPORT ifdefs, but consider applying it w/o them
(see some earlier comment from PaX Team on this issue, as it is considered
a bug). To have it work correctly, you'll also need removing
COMPLETELY_PIC.
One thing is missing: PIE_SUPPORT should be usable only for i386 (for
now).
Also added the support for propolice protection (that works for me and
catches memcpy/strcpy attacks (but needs a special gcc version).
Thanks, Peter
|
|
|
|
Here's the patch for the ldso bits for sh64. This is still in need of a bunch
of debugging, testing, etc. and is really only being submitted for general
completeness. This assumes that the previous patches I've submitted have
already been applied.
I plan on playing with this and buildroot some more later, as I'd definitely
like to see buildroot images for sh64.
|
|
For sh64 we need implicit access to the symtab, primarily to get at the
->st_other value. This presently isn't possible, as PERFORM_BOOTSTRAP_RELOC()
is invoked as such:
PERFORM_BOOTSTRAP_RELOC(rpnt, reloc_addr, symbol_addr, load_addr);
while we can easily get the symtab_index value from rpnt->r_info, this still
doesn't buy us easy access to the actual table. As such, I've modified
PERFORM_BOOTSTRAP_RELOC() to take an additional SYMTAB argument. Most
architectures aren't going to care about this, but unfortunately we don't
have any other options for sh64.
The following patch fixes up the API for what we need for sh64, and updates
the other architectures appropriately.
|
|
where a sizeof(foo) was changed to the sizeof a pointer. This caused
_dl_printf to complain a lot when debug is enabled (which itself revealed a bug
since it should have exited on buffer overflow), and let me to find another
bug, where memory failures would try to recursively call _dl_printf....
What a mess.
|
|
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
|
|
|
|
|
