From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH, RFC, RFT] ARM relocation fixes
Date: Mon, 02 Dec 2013 12:43:11 +0100 [thread overview]
Message-ID: <529C724F.3030006@gmail.com> (raw)
In-Reply-To: <20131202112846.GC24997@rocoto.smurfnet.nu>
[-- Attachment #1: Type: text/plain, Size: 3195 bytes --]
On 02.12.2013 12:28, Leif Lindholm wrote:
> On Mon, Dec 02, 2013 at 11:59:44AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 02.12.2013 11:53, Leif Lindholm wrote:
>>> On Sun, Dec 01, 2013 at 07:06:32AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>> Current ARM relocation doesn't handle the cases when the relocation cant
>>>> be satisfied directly (like thumb call over 1M of distance or jump24 to
>>>> thumb mode. Attached patch adds missing tampoline and missing relocation
>>>> handling to EFI code (it didn't allow to use ARM (no-Thumb) binary with
>>>> EFI).
>>>> I couldn't test it on either arm-efi or ARM64
>>>
>>> Amusingly, I wrote the attached
>> Nothing is attached to your mail. Right now could you pause work on
>> */dl.c: I'm reorganising them to declare more of it as platform
>> independent and unify handling (ARM dl.c is unnecessarily different from
>> other versions and forget some of ELF handling)
>
> Ok, I'll hold off.
>
>>> on Saturday, based on a bug report
>>> from Jon Masters @ Red Hat. Although an unlikely corner case, it does
>>> probably need the addition of grub_arch_dl_get_tramp_got_size() from
>>> your implementation in order to ensure the "veneers"[1] don't end up
>>> in a heap region different to and too far away from the one the module
>>> is loaded into.
>>>
>>> I'll have a look and a poke on both 32- and 64-bit stuff and respond..
>>>
>>> I would say the modifications to grub-mkimage for arm64 are probably
>>> unnessecary: AArch64 relative branch range is +-128MB, and I don't
>>> think we'll see grub kernel images that big.
>>
>> There are no changes of this kind to mkimage. I only added missing ARM
>> handling and the functions which now became mkimage-specific were moved
>> to it.
>
> Well, I was referring specifically to:
> --- a/util/grub-mkimagexx.c
> +++ b/util/grub-mkimagexx.c
> @@ -731,13 +731,13 @@ SUFFIX (relocate_addresses) (Elf_Ehdr *e, Elf_Shdr *sections,
> case R_AARCH64_JUMP26:
> case R_AARCH64_CALL26:
> {
> - grub_err_t err;
> sym_addr -= offset;
> sym_addr -= SUFFIX (entry_point);
> - err = grub_arm64_reloc_xxxx26((grub_uint32_t *)target,
> + if (!grub_arm_64_check_xxxx26_offset (sym_addr))
> + grub_util_error ("%s", _("CALL26 Relocation out of range"));
> +
> + grub_arm64_set_xxxx26_offset((grub_uint32_t *)target,
> sym_addr);
> - if (err)
> - grub_util_error ("%s", grub_errmsg);
> }
> break;
> default:
> which isn't wrong, but that offset test can only fail when your GRUB
> kernel is greater than 128MB in size.
>
True that's why it just aborts the image creation.
> /
> Leif
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
next prev parent reply other threads:[~2013-12-02 11:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-01 6:06 [PATCH, RFC, RFT] ARM relocation fixes Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-02 10:53 ` Leif Lindholm
2013-12-02 10:58 ` Leif Lindholm
2013-12-02 10:59 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-02 11:28 ` Leif Lindholm
2013-12-02 11:43 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2013-12-02 11:46 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-02 13:30 ` Leif Lindholm
2013-12-02 14:14 ` Leif Lindholm
2013-12-02 14:33 ` Leif Lindholm
2013-12-02 17:32 ` Leif Lindholm
2013-12-02 17:40 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-02 17:38 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-02 17:45 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-02 19:40 ` Leif Lindholm
2013-12-02 20:04 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-02 20:46 ` Leif Lindholm
2013-12-03 5:37 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-03 8:14 ` Leif Lindholm
2013-12-03 8:22 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-03 8:47 ` Leif Lindholm
2013-12-03 9:31 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-03 11:16 ` Leif Lindholm
2013-12-03 12:00 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-03 8:09 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-03 11:23 ` Leif Lindholm
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=529C724F.3030006@gmail.com \
--to=phcoder@gmail.com \
--cc=grub-devel@gnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).