Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 01 Feb 2019 15:14:30 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-arm@FreeBSD.org
Subject:   [Bug 235391] armv7: kernel.bin produced by buildkernel is corrupted.
Message-ID:  <bug-235391-7@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235391

            Bug ID: 235391
           Summary: armv7: kernel.bin produced by buildkernel is
                    corrupted.
           Product: Base System
           Version: CURRENT
          Hardware: arm
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: mmel@FreeBSD.org

Actually, ld.lld changed many years lasting status quo - file layout of
loadable sections in ELF file no longer correspond to in memory layout [1].=
=20

Unfortunately,  elftoolchain objcopy uses for generating kernel.bin images
doesn't handle this well and produces invalid binary files. The generated
binary follows ELF file layout, not a requested memory one.

This changed ld.lld behavior also means that we cannot load kernel to memory
and simply jump to start address to run it. Imo, many kernel developers use
this technique in early stage of porting kernel to new HW.

And I just noticed this, alignment of second load section looks very strang=
e, I
pretty sure that this is not a right output.

[1]
kernel generated by ld.lld:
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0xc0000034 0xc0000034 0x00120 0x00120 R   0x4
  INTERP         0x730e6c 0xc0730e6c 0xc0730e6c 0x0000d 0x0000d R   0x1
      [Requesting program interpreter: /red/herring]
  LOAD           0x000000 0xc0000000 0xc0000000 0x7f3804 0x7f3804 R E 0x1000
  LOAD           0x7f3840 0xc07f4840 0xc07f4840 0xcf848 0x2f37c0 RW  0x4000
  DYNAMIC        0x8c3040 0xc08c4040 0xc08c4040 0x00048 0x00048 RW  0x4
  GNU_RELRO      0x8c3040 0xc08c4040 0xc08c4040 0x00048 0x00048 R   0x1
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0
  NOTE           0x7c102c 0xc07c102c 0xc07c102c 0x00024 0x00024 R   0x4
  ARM_EXIDX      0x7d6774 0xc07d6774 0xc07d6774 0x1d090 0x1d090 R   0x4


exactly same (from identical objects) kernel generated by ld.bfd:
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  ARM_EXIDX      0x7b7f10 0xc07b7f10 0xc07b7f10 0x1d3b0 0x1d3b0 R   0x4
  PHDR           0x000034 0xc0000034 0xc0000034 0x000c0 0x000c0 R E 0x4
  INTERP         0x72d188 0xc072d188 0xc072d188 0x0000d 0x0000d R   0x1
      [Requesting program interpreter: /red/herring]
  LOAD           0x000000 0xc0000000 0xc0000000 0x8a5b0c 0xac8000 RWE 0x8000
  DYNAMIC        0x8a5aa4 0xc08a5aa4 0xc08a5aa4 0x00068 0x00068 RW  0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235391-7>