On 14.09.2017 10:03, Sergey Senozhatsky wrote:
On (09/14/17 16:40), Sergey Senozhatsky wrote:
[..]
powerpc and parisc handle kernel .opd section as well:
arch/powerpc/kernel/vmlinux.lds.S: .opd
arch/parisc/kernel/vmlinux.lds.S: .opd
for modules, arch-s define mod_arch_specific struct.
parisc has .opd
(fdesc offset should be the start of .opd,
fdesc_offset + sizeof(fdesc) * fdesc_count should be the .opd address range)
struct mod_arch_specific
{
unsigned long got_offset, got_count, got_max;
unsigned long fdesc_offset, fdesc_count, fdesc_max;
struct {
unsigned long stub_offset;
unsigned int stub_entries;
} *section;
int unwind_section;
struct unwind_table *unwind;
};
ia64 has .opd
struct mod_arch_specific {
struct elf64_shdr *core_plt; /* core PLT section */
struct elf64_shdr *init_plt; /* init PLT section */
struct elf64_shdr *got; /* global offset table */
struct elf64_shdr *opd; /* official procedure descriptors */
struct elf64_shdr *unwind; /* unwind-table section */
unsigned long gp; /* global-pointer for module */
void *core_unw_table; /* core unwind-table cookie returned
by unwinder */
void *init_unw_table; /* init unwind-table cookie returned
by unwinder */
unsigned int next_got_entry; /* index of next available got entry */
};
powerpc does not keep track of .opd, need to add
struct mod_arch_specific {
#ifdef __powerpc64__
unsigned int stubs_section; /* Index of stubs section in module */
unsigned int toc_section; /* What section is the TOC? */
bool toc_fixed; /* Have we fixed up .TOC.? */
#ifdef CONFIG_DYNAMIC_FTRACE
unsigned long toc;
unsigned long tramp;
#endif
#else /* powerpc64 */
/* Indices of PLT sections within module. */
unsigned int core_plt_section;
unsigned int init_plt_section;
#ifdef CONFIG_DYNAMIC_FTRACE
unsigned long tramp;
#endif
#endif /* powerpc64 */
/* List of BUG addresses, source line numbers and filenames */
struct list_head bug_list;
struct bug_entry *bug_table;
unsigned int num_bugs;
};
seems like we are looking at a solution here.
thoughts?
The basic concept of your proposal may work, and since it will avoid such
coding issues in the future I think it's probably the best solution.
Will you come up with a patch ? (I won't have time the next few days).
If yes,I'd be happy to test it on parisc.
Helge
