| Message ID | 6D39441BF12EF246A7ABCE6654B0235380AABFF9@HHMAIL01.hh.imgtec.org |
|---|---|
| State | New |
| Headers | show |
On Wed, 26 Oct 2016, Matthew Fortune wrote: > +# ifdef ELF_MACHINE_INIT_MAP > + ELF_MACHINE_INIT_MAP (bootstrap_map); > +# endif We don't encourage use of #ifdef like that. It's better to have an inline function defined everywhere and used unconditionally, for which most systems have a dummy definition (see dl-machine-reject-phdr.h and elf_machine_reject_phdr_p for an example - if you have a header for a single function, you don't need to update lots of dl-machine.h headers, just add a generic version - which has the comments detailing the semantics of the function and when it's needed - and a MIPS version).
Joseph Myers <joseph@codesourcery.com> writes: > On Wed, 26 Oct 2016, Matthew Fortune wrote: > > > +# ifdef ELF_MACHINE_INIT_MAP > > + ELF_MACHINE_INIT_MAP (bootstrap_map); # endif > > We don't encourage use of #ifdef like that. It's better to have an > inline function defined everywhere and used unconditionally, for which > most systems have a dummy definition (see dl-machine-reject-phdr.h and > elf_machine_reject_phdr_p for an example - if you have a header for a > single function, you don't need to update lots of dl-machine.h headers, > just add a generic version - which has the comments detailing the > semantics of the function and when it's needed - and a MIPS version). Thanks Joseph. It's been a while since I did a glibc patch and couldn't remember the recommended approach. Do you think I should add a whole new header for this? Or, since this is directly related to the reject_phdr feature for MIPS and only MIPS is affected then I could just add it to dl-machine-reject-phdr.h? Matthew
On 10/26/2016 03:01 PM, Matthew Fortune wrote: > Joseph Myers <joseph@codesourcery.com> writes: >> On Wed, 26 Oct 2016, Matthew Fortune wrote: >> >>> +# ifdef ELF_MACHINE_INIT_MAP >>> + ELF_MACHINE_INIT_MAP (bootstrap_map); # endif >> >> We don't encourage use of #ifdef like that. It's better to have an >> inline function defined everywhere and used unconditionally, for which >> most systems have a dummy definition (see dl-machine-reject-phdr.h and >> elf_machine_reject_phdr_p for an example - if you have a header for a >> single function, you don't need to update lots of dl-machine.h headers, >> just add a generic version - which has the comments detailing the >> semantics of the function and when it's needed - and a MIPS version). > > Thanks Joseph. It's been a while since I did a glibc patch and couldn't > remember the recommended approach. > > Do you think I should add a whole new header for this? Or, since this > is directly related to the reject_phdr feature for MIPS and only MIPS > is affected then I could just add it to dl-machine-reject-phdr.h? Wouldn't it be easier and more maintainable just to unconditionally zero-initialize the structure, as I did in the original patch? -Sandra
Sandra Loosemore <sandra@codesourcery.com> writes: > On 10/26/2016 03:01 PM, Matthew Fortune wrote: > > Joseph Myers <joseph@codesourcery.com> writes: > >> On Wed, 26 Oct 2016, Matthew Fortune wrote: > >> > >>> +# ifdef ELF_MACHINE_INIT_MAP > >>> + ELF_MACHINE_INIT_MAP (bootstrap_map); # endif > >> > >> We don't encourage use of #ifdef like that. It's better to have an > >> inline function defined everywhere and used unconditionally, for > >> which most systems have a dummy definition (see > >> dl-machine-reject-phdr.h and elf_machine_reject_phdr_p for an example > >> - if you have a header for a single function, you don't need to > >> update lots of dl-machine.h headers, just add a generic version - > >> which has the comments detailing the semantics of the function and > when it's needed - and a MIPS version). > > > > Thanks Joseph. It's been a while since I did a glibc patch and > > couldn't remember the recommended approach. > > > > Do you think I should add a whole new header for this? Or, since this > > is directly related to the reject_phdr feature for MIPS and only MIPS > > is affected then I could just add it to dl-machine-reject-phdr.h? > > Wouldn't it be easier and more maintainable just to unconditionally > zero-initialize the structure, as I did in the original patch? I was just trying to factor in the comments from Roland on the original patch. I don't know if the initialisation cost outweighs the drawback of not simply initialising the whole structure. I'm happy to be led by other opinions though. Matthew
On Wed, 26 Oct 2016, Matthew Fortune wrote: > Do you think I should add a whole new header for this? Or, since this > is directly related to the reject_phdr feature for MIPS and only MIPS > is affected then I could just add it to dl-machine-reject-phdr.h? If you can argue that there is no possible need for this new function other than with the reject_phdr feature and include that explanation in the comments in the header, sharing the header seems reasonable. Otherwise it should be a separate header.
Sandra Loosemore <sandra@codesourcery.com> writes: > On 10/26/2016 03:01 PM, Matthew Fortune wrote: > > Joseph Myers <joseph@codesourcery.com> writes: > >> On Wed, 26 Oct 2016, Matthew Fortune wrote: > >> > >>> +# ifdef ELF_MACHINE_INIT_MAP > >>> + ELF_MACHINE_INIT_MAP (bootstrap_map); # endif > >> > >> We don't encourage use of #ifdef like that. It's better to have an > >> inline function defined everywhere and used unconditionally, for > >> which most systems have a dummy definition (see > >> dl-machine-reject-phdr.h and elf_machine_reject_phdr_p for an example > >> - if you have a header for a single function, you don't need to > >> update lots of dl-machine.h headers, just add a generic version - > >> which has the comments detailing the semantics of the function and > when it's needed - and a MIPS version). > > > > Thanks Joseph. It's been a while since I did a glibc patch and > > couldn't remember the recommended approach. > > > > Do you think I should add a whole new header for this? Or, since this > > is directly related to the reject_phdr feature for MIPS and only MIPS > > is affected then I could just add it to dl-machine-reject-phdr.h? > > Wouldn't it be easier and more maintainable just to unconditionally > zero-initialize the structure, as I did in the original patch? I'd like to get some consensus on the best solution here before I do another implementation. We either go for: 1) The bare minimum to initialise just the fields that must be zero for successful execution on a per architecture basis (and live with the associated risk of missing some) or 2) Unconditionally zero the whole l_mach link_map_machine structure Or 3) Unconditionally zero the entire link_map Given these I'd actually go for (2) as a good balance. Thanks, Matthew
diff --git a/elf/rtld.c b/elf/rtld.c index 647661c..31539a4 100644 --- a/elf/rtld.c +++ b/elf/rtld.c @@ -364,6 +364,9 @@ _dl_start (void *arg) do not have to use the temporary bootstrap_map. Global variables are initialized to zero by default. */ #ifndef DONT_USE_BOOTSTRAP_MAP +# ifdef ELF_MACHINE_INIT_MAP + ELF_MACHINE_INIT_MAP (bootstrap_map); +# endif # ifdef HAVE_BUILTIN_MEMSET __builtin_memset (bootstrap_map.l_info, '\0', sizeof (bootstrap_map.l_info)); # else diff --git a/sysdeps/mips/dl-machine.h b/sysdeps/mips/dl-machine.h index 8c0b40e..d929477 100644 --- a/sysdeps/mips/dl-machine.h +++ b/sysdeps/mips/dl-machine.h @@ -93,6 +93,13 @@ do { if ((l)->l_info[DT_MIPS (RLD_MAP_REL)]) \ # define ELF_MACHINE_NAN2008 0 #endif +/* Initialise the machine dependent parts of a map. This is not normally + required unless the map is allocated on the stack. */ +#define ELF_MACHINE_INIT_MAP(MAP) \ +do { (MAP)->l_mach.fpabi = 0; \ + (MAP)->l_mach.odd_spreg = 0; \ + } while (0) + /* Return nonzero iff ELF header is compatible with the running host. */ static inline int __attribute_used__ elf_machine_matches_host (const ElfW(Ehdr) *ehdr)