This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] bfd: xtensa: ignore overflow in hight part of const16 relocation
- From: Max Filippov <jcmvbkbc at gmail dot com>
- To: Sterling Augustine <augustine dot sterling at gmail dot com>
- Cc: binutils at sourceware dot org, Eric Tsai <erictsai at cadence dot com>, linux-xtensa at linux-xtensa dot org
- Date: Fri, 7 Dec 2018 13:38:17 -0800
- Subject: Re: [PATCH] bfd: xtensa: ignore overflow in hight part of const16 relocation
- References: <firstname.lastname@example.org> <CAGSvup-AQqG2_MQhn7wgO+SWdnWwTKR=LSXQi00+RktgumcUyg@mail.gmail.com>
On Fri, Dec 7, 2018 at 1:31 PM email@example.com
> On Fri, Dec 7, 2018 at 1:17 PM Max Filippov <firstname.lastname@example.org> wrote:
> > 32-bit constants loaded by two const16 opcodes that involve relocation
> > (e.g. calculated as a sum of a symbol and a constant) may overflow,
> > resulting in linking error with the following message:
> > dangerous relocation: const16: cannot encode: (_start+0x70000000)
> > They whould wrap around instead.
> > bfd/
> > 2018-12-07 Max Filippov <email@example.com>
> > * elf32-xtensa.c (elf_xtensa_do_reloc): Only use bits 16..31 of
> > the relocated value for the high part const16 immediate.
> This is generally OK. I would probably change the comment to, "Ignore
> high sixteen bits". The way it is worded now it sounds like a 32-bit
> overflow, so more than ~4GB.
It is a 32-bit overflow of the relocated value, and when the value is
shifted right by 16 to extract immediate field for the const16 it doesn't
fit into that 16-bit field.
So the fix is to ignore all bits above the bit 31 of the relocated value,
i.e. to only use bits 16..31 for the const16 immediate.