This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] x86: adjust relocation overflow complaint types
- From: "Jan Beulich" <jbeulich at novell dot com>
- To: "Michael Matz" <matz at suse dot de>
- Cc: <binutils at sources dot redhat dot com>
- Date: Mon, 08 Aug 2005 12:39:39 -0600
- Subject: Re: [PATCH] x86: adjust relocation overflow complaint types
>> @@ -95,7 +95,7 @@ static reloc_howto_type elf_howto_table[
>> HOWTO(R_386_16, 0, 1, 16, FALSE, 0, complain_overflow_bitfield,
>> bfd_elf_generic_reloc, "R_386_16",
>> TRUE, 0xffff, 0xffff, FALSE),
>> - HOWTO(R_386_PC16, 0, 1, 16, TRUE, 0, complain_overflow_bitfield,
>> + HOWTO(R_386_PC16, 0, 1, 16, TRUE, 0, complain_overflow_signed,
>This is too eager when compiling in .code16 mode, and breaks
>linking current dosemu bios.S. It uses something like this:
Hmm, perhaps. But then we shouldn't just change R_386_PC16 to use 'bitfield' overflow checking, but also R_386_PC8; the whole point of the patch was to adjust the mismatches between R_386_PC8/R_386_PC16 and R_386_8/R_386_16.
>This is because bfd now thinks the jump is out of range. It _would_
>be in a 32bit segment, but in that we wouldn't use a PC16
>relocation. Due to 16bit offset wrap around the jump to 0x420 is >representable just fine.
Agreed.
>When I revert this part of your patch I can link it and the result is:
As said above, simply reverting is not the right thing here...
>I don't know how to teach bfd to make a difference between
>.code16 and .code32 (or .code64 for that matter) in doing the
>overflow checking.
In fact, there's no way (without additional relocation types), since this information is simply lost (there are no section attributes representing this, and even if there were mixing 16- and 32-bit code in one section would still need to be allowed).
The problem I have with adjusting the patch is that code like
.code32 # or .code64
addw $abs, %ax
(again) wouldn't be checked for correctness by the linker...
For that reason I'd prefer hearing opinions of one or more of the x86 maintainers before submitting a (corrective) patch...
Jan