Re: Has the dynamic section to be read-write?

[Andreas Jaeger <aj at suse dot de>]

>>>>> 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