This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
On Wed, Aug 01, 2001 at 01:18:46AM -0700, Ulrich Drepper wrote: > Andreas Jaeger <aj@suse.de> writes: > > > I haven't seen binutils patches for this yet and looking at his > > description he seems to do the reordering in his prelinker. > > For now this is true I assume. Yes, for now I do the .rel{,a}.* except .rel{,a}.plt merging and reordering in the prelinker. It can be done in ld too though. I'll try to cook up a patch soon. Sun linker uses -z combreloc to request this, maybe this should be default GNU ld behaviour though and have -z nocombreloc to disable it. BTW: I'm not doing a simple qsort to reorder the relocs, I do 2 qsorts and some magic in between, so that: a) R_*_RELATIVE symbols come last, sorted by increasing r_offset b) the rest of relocs are sorted by r_offset as long as they have different ELFW(R_SYM). If they have the same R_SYM, they are together, with R_*_COPY symbols coming last, R_*_JMP_SLOT before that and other relocs first, in each subcategory sorted by increasing r_offset This way, the locality is IMHO better than if they would be simply sorted by ELFW(R_SYM), if there are no symbols with the same R_SYM, aside from R_*_RELATIVE the order is the same as ld sorted them so far (and R_*_RELATIVE relocs are expected not to be done for relocated libraries and grouping them together means they can be cheaply skipped all at once). Jakub
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |