grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).