From: Thiemo Seufer <ths@networkno.de>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, sam@ravnborg.org
Subject: Re: [PATCH] fix modpost segfault for 64bit mipsel kernel
Date: Thu, 20 Apr 2006 01:19:00 +0100 [thread overview]
Message-ID: <20060420001900.GC30806@networkno.de> (raw)
In-Reply-To: <20060419.112228.108306767.anemo@mba.ocn.ne.jp>
Atsushi Nemoto wrote:
> On Mon, 17 Apr 2006 17:27:42 +0100, Thiemo Seufer <ths@networkno.de> wrote:
> > So it is the
> >
> > r.r_info = TO_NATIVE(rela->r_info);
> >
> > in modpost.c which breaks both SYM and TYPE because it assumes a
> > 64bit integer. The proper solution would be to add a Elf64_Mips_Rela
> > structure (with lots of nearly identical duplicated code), the hack
> > would be to cast r_info to a 32bit integer for mips, before feeding
> > it to TO_NATIVE (which works until somebody asks for the TYPE, then
> > a separate mips64 version becomes inevitable.)
>
> I'd like to fix in _proper_ way. Please review. Thanks.
>
>
> 64bit mips has different r_info layout. This patch fixes modpost
> segfault for 64bit little endian mips kernel.
>
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index cd00e9f..4ce95c6 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -710,7 +710,20 @@ static void check_sec_ref(struct module
> Elf_Rela r;
> const char *secname;
> r.r_offset = TO_NATIVE(rela->r_offset);
> +#if KERNEL_ELFCLASS == ELFCLASS64
> + if (hdr->e_machine == EM_MIPS) {
> + unsigned int r_sym =
> + ELF64_MIPS_R_SYM(rela->r_info);
> + unsigned int r_type =
> + ELF64_MIPS_R_TYPE(rela->r_info);
> + r.r_info = ELF_R_INFO(TO_NATIVE(r_sym),
> + TO_NATIVE(r_type));
[snip]
> +/* The 64-bit MIPS ELF ABI uses an unusual reloc format. */
> +typedef struct
> +{
> + Elf32_Word r_sym; /* Symbol index */
> + unsigned char r_ssym; /* Special symbol for 2nd relocation */
> + unsigned char r_type3; /* 3rd relocation type */
> + unsigned char r_type2; /* 2nd relocation type */
> + unsigned char r_type1; /* 1st relocation type */
> +} _Elf64_Mips_R_Info;
[snip]
> +#define ELF64_MIPS_R_TYPE(i) \
> + (((_Elf64_Mips_R_Info_union)(i)).r_info_fields.r_type1 \
> + | ((Elf32_Word)(__extension__ (_Elf64_Mips_R_Info_union)(i) \
> + ).r_info_fields.r_type2 << 8) \
> + | ((Elf32_Word)(__extension__ (_Elf64_Mips_R_Info_union)(i) \
> + ).r_info_fields.r_type3 << 16) \
> + | ((Elf32_Word)(__extension__ (_Elf64_Mips_R_Info_union)(i) \
> + ).r_info_fields.r_ssym << 24))
Why is it the right thing to combine the type info into a 32bit word?
It will never get used as such for MIPS ELF64. I would have expected
something like:
#define ELF64_MIPS_R_INFO(sym,ssym,t3,t2,t1) \
{( \
_Elf64_Mips_R_Info info = { \
.r_sym = sym, \
.r_ssym = ssym, \
.r_type3 = t3, \
.r_type2 = t2, \
.r_type1 = t1, \
} \
(Elf64_Xword)info; \
)}
without a corresponding ELF64_MIPS_R_TYPE, and then:
if (hdr->e_ident[EI_CLASS] == ELFCLASS64
&& hdr->e_machine == EM_MIPS) {
_Elf64_Mips_R_Info info = (_Elf64_Mips_R_Info)r.r_info;
r.r_info = ELF64_MIPS_R_INFO(TO_NATIVE(info.r_sym),
info.r_ssym, info.r_type3,
info.r_type2, info.r_type1);
}
Thiemo
next prev parent reply other threads:[~2006-04-20 0:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-17 12:00 [PATCH] fix modpost segfault for 64bit mipsel kernel Atsushi Nemoto
2006-04-17 12:53 ` Thiemo Seufer
2006-04-17 14:07 ` Thiemo Seufer
2006-04-17 15:47 ` Atsushi Nemoto
2006-04-17 16:27 ` Thiemo Seufer
2006-04-19 2:22 ` Atsushi Nemoto
2006-04-20 0:19 ` Thiemo Seufer [this message]
2006-04-20 16:02 ` Atsushi Nemoto
2006-04-20 16:23 ` Thiemo Seufer
2006-04-20 17:05 ` Atsushi Nemoto
2006-04-21 13:57 ` Thiemo Seufer
2006-04-17 13:40 ` Sam Ravnborg
2006-04-17 16:03 ` Atsushi Nemoto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060420001900.GC30806@networkno.de \
--to=ths@networkno.de \
--cc=anemo@mba.ocn.ne.jp \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=sam@ravnborg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.