This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Can la_symbind's flags parameter be modified outside of the function scope?


la_symbind and la_pltenter both get a flags pointer to a bitmask that contains two flags: LA_SYMB_NOPLTENTER and LA_SYMB_NOPLTEXIT. In theory either la_symbind or la_pltenter could stash the flags pointer in a variable out of scope of those functions to be modified based upon some other trigger. Right now changing these flags in that variable wonât work as expected because whether the PLT auditing functions are invoked is calculate and stored in cache after the return of symbind and pltenter. I would like to formalize this behavior and explicitly state that changing the variable pointed to by flags outside of the scope of symbind and pltenter cannot be used to re-enable PLT auditing functions.

Why this matters:
If all the auditing libraries set both  LA_SYMB_NOPLTENTER and LA_SYMB_NOPLTEXIT, and since there is no way to re-enable PLT auditing functions for that function, we can finalize the symbol in the GOT which will improve performance considerably. 

On the other hand, if we decide that you can modify the bitmask pointed to by flags outside of the scope of the symbind and pltenter, then we need to remove the cache we use to determine whether to call any PLT auditing function for any audit library and we would also like to add a new feature which would allow us to choose to finalize a symbol in the GOT when we have no further interest in auditing it from this library. We have already implemented this feature but we be think that by explicitly specifying the semantic that the variable pointed to by flags cannot be modified outside of the scope of the symbind and pltenter functions we can implement it as an optimization without changing the interface to the audit library. 

Since modifying the bitmask pointed to by flags outside of the scope of those functions would not trigger a recalculation of the cached value determining whether we should invoke any PLT auditing function for any library, we do not think that we would be breaking any existing behavior.

Carlos agrees with the logic of not allowing modification of the variable pointed to by the flags parameter but he asked me to run it past the broader community to make sure that is the consensus before I document and define the behavior.

-ben


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]