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: 23 Nov 1999 09:23:02 +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>
>>>>> 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.
Thanks for the fast answer.
Do I understand you correctly that you suggest to change the member
l_info from struct link_map from:
ElfW(Dyn) *l_info[DT_NUM + DT_PROCNUM + DT_VERSIONTAGNUM + DT_EXTRANUM];
to
ElfW(Dyn) l_info[DT_NUM + DT_PROCNUM + DT_VERSIONTAGNUM + DT_EXTRANUM];
?
Since ElfW(Dyn) already contains the d_tag and we're only interested
in d_un:
typedef struct
{
Elf32_Sword d_tag; /* Dynamic entry type */
union
{
Elf32_Word d_val; /* Integer value */
Elf32_Addr d_ptr; /* Address value */
} d_un;
} Elf32_Dyn;
We could change this to (I'm just considering the 32bit case here):
typedef union
{
Elf32_Word d_val; /* Integer value */
Elf32_Addr d_ptr; /* Address value */
} Elf32_Dyn_d_un;
and use for l_info:
Elf(Dyn_d_un) l_info[DT_NUM + DT_PROCNUM + DT_VERSIONTAGNUM + DT_EXTRANUM];
This would imply the same size as the old table - just one copy more
during the initialization but since we save one pointer it should be
faster. All the l_info[DT_PLTRELSZ]->d_un.d_val accesses will become
l_info[DT_PLTRELSZ].d_val .
What do you think? Should I provide patches?
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.rhein-neckar.de