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

[Andreas Jaeger <aj at suse dot 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