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 Fri, Aug 03, 2001 at 09:57:11AM -0700, Ulrich Drepper wrote: > Jakub Jelinek <jakub@redhat.com> writes: > > > 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. > > Right. And I think they put the RELATIVE reloations at the beginning. Well, first I thought they do (and it makes more sense to do that). But a quick look at elfdump -r /lib/libc.so.1 | less on Solaris 8 shows it is not true: Relocation: .SUNW_reloc type offset addend section with respect to R_SPARC_GLOB_DAT 0xb8e64 0 .SUNW_reloc __yday_to_month R_SPARC_GLOB_DAT 0xb8f8c 0 .SUNW_reloc _lib_version R_SPARC_GLOB_DAT 0xb8fa8 0 .SUNW_reloc _siguhandler R_SPARC_GLOB_DAT 0xb8e10 0 .SUNW_reloc __huge_val R_SPARC_GLOB_DAT 0xb8f18 0 .SUNW_reloc _daylight R_SPARC_GLOB_DAT 0xb8f6c 0 .SUNW_reloc _numeric R_SPARC_GLOB_DAT 0xb8f44 0 .SUNW_reloc _timezone R_SPARC_GLOB_DAT 0xb8dd0 0 .SUNW_reloc _getdate_err R_SPARC_GLOB_DAT 0xb8f54 0 .SUNW_reloc optarg R_SPARC_32 0xbd948 0 .SUNW_reloc __wcrtomb_sb R_SPARC_32 0xba578 0 .SUNW_reloc _ex_deregister R_SPARC_32 0xbade0 0 .SUNW_reloc free R_SPARC_GLOB_DAT 0xb8f24 0 .SUNW_reloc free R_SPARC_32 0xbd920 0 .SUNW_reloc __mblen_sb R_SPARC_32 0xbdcd0 0 .SUNW_reloc __wcsftime_std R_SPARC_32 0xbd934 0 .SUNW_reloc __btowc_sb ... R_SPARC_32 0xbdad4 0 .SUNW_reloc __towctrans_std R_SPARC_32 0xbde58 0 .SUNW_reloc __nl_langinfo_std R_SPARC_32 0xbdcc8 0 .SUNW_reloc __strptime_std R_SPARC_RELATIVE 0xb81d4 0xbab48 .SUNW_reloc R_SPARC_RELATIVE 0xb81fc 0xa46f4 .SUNW_reloc R_SPARC_RELATIVE 0xb8200 0xa46fc .SUNW_reloc R_SPARC_RELATIVE 0xb8204 0xa4700 .SUNW_reloc R_SPARC_RELATIVE 0xb8208 0xa4708 .SUNW_reloc R_SPARC_RELATIVE 0xb820c 0xa4710 .SUNW_reloc R_SPARC_RELATIVE 0xb8210 0xa4718 .SUNW_reloc R_SPARC_RELATIVE 0xb8214 0xa4724 .SUNW_reloc ... R_SPARC_RELATIVE 0xbdf98 0xa5cfc .SUNW_reloc R_SPARC_RELATIVE 0xbdf9c 0xa5d00 .SUNW_reloc R_SPARC_RELATIVE 0xbdfa0 0xa5d08 .SUNW_reloc R_SPARC_RELATIVE 0xbdfa4 0xa5d10 .SUNW_reloc Relocation: .rela.plt type offset addend section with respect to R_SPARC_JMP_SLOT 0xb9004 0 .rela.plt _ld_libc R_SPARC_JMP_SLOT 0xb9010 0 .rela.plt _mutex_lock ... Now I don't know if it is desired, or if they just screwed up the comparison function (like they could not get R_SPARC_RELATIVE right neither for sparc32 nor sparc64, but each time with a different bug). > And more importantly: they define DT_RELACOUNT/DT_RELCOUNT to make it > possible to speed up the processing (or ignore the relocations). Sure, I do so too in prelink program and ld -z combreloc would do too. Jakub
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |