This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> On Wednesday 08 September 2004 19:24, Andreas Jaeger wrote: > > Roland McGrath <roland@redhat.com> writes: > > >> -static inline void > > >> +inline void > > >> +__attribute ((always_inline)) > > >> elf_machine_rela (struct link_map *map, const Elf64_Rela *reloc, > > >> const Elf64_Sym *sym, const struct r_found_version *version, > > >> void *const reloc_addr_arg) > > > > > > Does this really do the right thing in all of 3.[345]? > > > I would think this would generate an external entry point too. > > > > It seems so :-( [...] > > 0000000000000000 t elf_machine_rela.0 Not external. The question is why is it there at all? > Wait - this seems to be produced even with the current glibc without my > changes (glibc compiled by GCC 3.3): > nm /lib64/ld-linux-x86-64.so.2 |grep elf_machine_rela > 0000000000000d40 t elf_machine_rela.0 > 0000000000007fa0 t elf_machine_rela.0 > 000000000000d010 t elf_machine_rela.0 > 0000000000000d70 t elf_machine_rela_relative.1 > 0000000000008330 t elf_machine_rela_relative.1 These are just uninlined statics.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |