2

I have come across a strange problem in the arm obj-copy. Am I doing something wrong or have I come across a bug?

I want to pad my image with zeroes up to 0x1000 (4096) alignment and I do this padding via the below link script. The problem is that obj-copy does not copy the whole padding, it stops at 0x400 for some reason.

I have used objdump to evaluate my section and it seems to be of correct size for padding to 0x1000.

How come the hexdump of my binary is not padded correctly in case of using 0x1000 padding? I use objcopy the following way to create my binary:

 /usr/local/armhf/r27/bin/arm-axis-eabi-objcopy -I elf32-little -O binary myobj.o myobj.bin

Objdump:

.fill         0000080c  009117f4  009117f4  000117f4  2**0
              CONTENTS, ALLOC, LOAD, DATA

009117f4 l    d  .fill  00000000 .fill
00912000 g       .fill  00000000 __Eloadimg

link script:

__Edata = .;

.fill :
{
  FILL(0x00000000);
  BYTE(0x00);
  . = ALIGN(0x1000);
}

__Eloadimg = .;
ria
  • 339
  • 2
  • 9
  • there are some articles on this ALIGN on gnu is bad, it is architecture dependent (meaning x86 it does one thing, mips another, arm another), but BALIGN (certainly for assembly would hope for linker scripts) is a bit more both obvious and consistent across the targets. – old_timer Sep 13 '18 at 14:26
  • I am sure its not a bug, but instead it works how it works and folks get used to that. – old_timer Sep 13 '18 at 14:26
  • 1
    And it would not surprise me one bit if the gnu assembler and gnu linker (both part of binutils) use ALIGN differently from each other. – old_timer Sep 13 '18 at 14:27
  • You could try `.balign` or you can use `.fill ALIGN(0x1000) : {}`. I think that you might not even include `.fill` in the output section of the image. Make sure you denote `.fill` as an allocted section. Otherwise, it might not make it to the binary. Generate a map file to ensure how it is located/allocated. – artless noise Sep 13 '18 at 14:33
  • BALIGN gave me syntax error when building – ria Sep 14 '18 at 09:12
  • 1
    Did you create a map file and look at it? `ld` is not very user friendly, but it is rare to find actual bugs. I have thought there were bugs many times only to find it was some weird syntax issue (like a typo, etc). Definitely generate a map file and show the output for the section here from the map file. – artless noise Sep 14 '18 at 14:55
  • I did view a hexdump of my image. It was correctly padded (with 0's) when I used e.g. 0x20, 0x100 and 0x400 alignment. But 0x1000 aligment gives same result as 0x400. I can post a map file when coming back to work. – ria Sep 14 '18 at 17:27
  • Thanks "artless noise", when I checked the map file I see that the .fill segment is of correct size for padding up to 0x1000. – ria Sep 18 '18 at 11:26

1 Answers1

1

I found the error and it was mine. After evaluating all calculations in my linker script I found out that MEM_START was 0x905c00 which made a hexdump of the binary look non aligned in the case of 0x1000 alignment.

ria
  • 339
  • 2
  • 9