This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
Re: Has the dynamic section to be read-write?
- To: Roland McGrath <roland at frob dot com>
- Subject: Re: Has the dynamic section to be read-write?
- From: Andreas Jaeger <aj at suse dot de>
- Date: 24 Nov 1999 08:09:07 +0100
- Cc: "GNU C. library Alpha Tester List" <libc-alpha at sourceware dot cygnus dot com>, "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>, Florian Lohoff <flo at rfc822 dot org>
- References: <199911230742.CAA15691@frob.com> <u8vh6tfwgp.fsf@gromit.rhein-neckar.de>
After having looked further into this issues, I'm beginning to ask
myself what consequences such a change would have. I proposed
changing struct link_map which is exported in <link.h>. Do other
programs relay on the exact interface? A change would break binary
compatibility.
Those members have the following header:
/* All following members are internal to the dynamic linker.
They may change without notice. */
So it seems to be ok to change them.
Thanks Roland for your comments, you're right, we need a way to mark
missing values.
Andreas
>>>>> Andreas Jaeger writes:
>>>>> Roland McGrath writes:
>> The dynamic linker code just uses that space to cache its own values
>> because it was convenient and writable already anyway. On other platforms
>> the ABI says the dynamic section has to be writable, I think the only
>> reason being so the DT_DEBUG slot can be modified by the dynamic linker.
>> Probably the best thing to do is just rewrite that part of the data
>> structure so that it caches values from the dynamic section (modified as
>> convenient for the dynamic linker) directly in its own array rather than
>> using an array of pointers into the dynamic section as it does now.
AJ> Thanks for the fast answer.
AJ> Do I understand you correctly that you suggest to change the member
AJ> l_info from struct link_map from:
AJ> ElfW(Dyn) *l_info[DT_NUM + DT_PROCNUM + DT_VERSIONTAGNUM + DT_EXTRANUM];
AJ> to
AJ> ElfW(Dyn) l_info[DT_NUM + DT_PROCNUM + DT_VERSIONTAGNUM + DT_EXTRANUM];
AJ> ?
AJ> Since ElfW(Dyn) already contains the d_tag and we're only interested
AJ> in d_un:
AJ> typedef struct
AJ> {
AJ> Elf32_Sword d_tag; /* Dynamic entry type */
AJ> union
AJ> {
AJ> Elf32_Word d_val; /* Integer value */
AJ> Elf32_Addr d_ptr; /* Address value */
AJ> } d_un;
AJ> } Elf32_Dyn;
AJ> We could change this to (I'm just considering the 32bit case here):
AJ> typedef union
AJ> {
AJ> Elf32_Word d_val; /* Integer value */
AJ> Elf32_Addr d_ptr; /* Address value */
AJ> } Elf32_Dyn_d_un;
AJ> and use for l_info:
AJ> Elf(Dyn_d_un) l_info[DT_NUM + DT_PROCNUM + DT_VERSIONTAGNUM + DT_EXTRANUM];
AJ> This would imply the same size as the old table - just one copy more
AJ> during the initialization but since we save one pointer it should be
AJ> faster. All the l_info[DT_PLTRELSZ]->d_un.d_val accesses will become
AJ> l_info[DT_PLTRELSZ].d_val .
AJ> What do you think? Should I provide patches?
AJ> Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.rhein-neckar.de