Hi toolchain, kernel folks,

I'm seeing an interesting thing on .got and .bss sections of
arch/arm/boot/compressed/vmlinux, and really need your expertise to
shed some lights.

I have an uninitialized variable 'uart_base' defined in misc.c.

static unsigned long uart_base;

$ arm-linux-gnueabi-objdump -D arch/arm/boot/compressed/misc.o

Disassembly of section .bss:

00000000 <uart_base>:
   0:   00000000        andeq   r0, r0, r0
00000004 <__machine_arch_type>:
   4:   00000000        andeq   r0, r0, r0
[...]

And section layout looks like the following.

$ arm-linux-gnueabi-objdump -h arch/arm/boot/compressed/vmlinux

SECTIOINS {
  ...

  _etext = .;

  _got_start = .;
  .got                  : { *(.got) }
  _got_end = .;
  .got.plt              : { *(.got.plt) }
  _edata = .;

  . = ALIGN(4);
  __bss_start = .;
  .bss                  : { *(.bss) }
  _end = .;

  ...
}

$ arm-linux-gnueabi-objdump -h arch/arm/boot/compressed/vmlinux

arch/arm/boot/compressed/vmlinux:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         001c474c  00000000  00000000  00008000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .got          00000028  001c474c  001c474c  001cc74c  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 .got.plt      0000000c  001c4774  001c4774  001cc774  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          00000020  001c4780  001c4780  001cc780  2**2
                  ALLOC
  4 .stack        00001000  001c47a0  001c47a0  001cc780  2**0
                  ALLOC
  5 .comment      0000002a  00000000  00000000  001cc780  2**0
                  CONTENTS, READONLY
  6 .ARM.attributes 00000031  00000000  00000000  001cc7aa  2**0
                  CONTENTS, READONLY

I'm able to see uart_base in vmlinux objdump ...

$ arm-linux-gnueabi-objdump -t arch/arm/boot/compressed/vmlinux
[relevant only, and sorted]
00000000 l    d  .text  00000000 .text
001c474c l    d  .got   00000000 .got
001c4774 l    d  .got.plt       00000000 .got.plt
001c4780 l    d  .bss   00000000 .bss

003968e4 g       *ABS*  00000000 _image_size
001c474c g       *ABS*  00000000 _got_start
001c4774 g       *ABS*  00000000 _got_end
001c4780 g       *ABS*  00000000 _edata

001c4780 g       *ABS*  00000000 __bss_start
001c4780 l     O .bss   00000004 uart_base
001c4798 g     O .bss   00000004 malloc_ptr
001c478c g     O .bss   00000004 output_ptr
001c479c g     O .bss   00000004 malloc_count
001c4794 g     O .bss   00000004 free_mem_end_ptr
001c4788 g     O .bss   00000004 output_data
001c4784 g     O .bss   00000004 __machine_arch_type
001c4790 g     O .bss   00000004 free_mem_ptr
001c47a0 g       *ABS*  00000000 _end

... but I can not see it in the zImage (all others in .bss seem still
there).

$ xxd arch/arm/boot/zImage | tail
01c4740: 3ef1 1400 be52 9f58 e468 3900 4c47 1c00  >....R.X.h9.LG..
                                       ^_got_start (why is it?)
01c4750: 9847 1c00 1043 0000 8c47 1c00 9c47 1c00  .G...C...G...G..
         ^malloc_ptr         ^output_ptr
01c4760: 9447 1c00 080a 0000 8847 1c00 8447 1c00  .G.......G...G..
         ^free_mem_end_ptr             ^__machine_arch_type
01c4770: 9047 1c00 0000 0000 0000 0000 0000 0000  .G..............
         ^free_mem_ptr

The following is a run-time memdump at _got_start.

Before recalculation:
9056304C: 001C474C 001C4798 00004310 001C478C  001C479C 001C4794 00000A08 
001C4788
          ^_got_start (why is it?)
9056306C: 001C4784 001C4790 00000000 00000000  00000000 EDFE0DD0 4C010000 
38000000

After recalculation (for .bss entries, the delta is 9039EA50, for
others in .got, delta is 9039E900):
9056304C: 9056304C 905631E8 903A2C10 905631DC  905631EC 905631E4 9039F308 
905631D8
9056306C: 905631D4 905631E0 00000000 00000000  00000000 73FBC000 4C010000 
38000000

QUESTION: Where is the .bss section of uart_base?

Now, I remove the 'static' to have 'unsigned long uart_base', and
dump the same stuff to compare.

$ arm-linux-gnueabi-objdump -D arch/arm/boot/compressed/misc.o

Disassembly of section .bss:

00000000 <__machine_arch_type>:
   0:   00000000        andeq   r0, r0, r0

00000004 <uart_base>:
   4:   00000000        andeq   r0, r0, r0

I'm able to see uart_base in vmlinux objdump ...

$ arm-linux-gnueabi-objdump -t arch/arm/boot/compressed/vmlinux
[relevant only, and sorted]
00000000 l    d  .text  00000000 .text
001c4720 l    d  .got   00000000 .got
001c474c l    d  .got.plt       00000000 .got.plt
001c4758 l    d  .bss   00000000 .bss

003968e4 g       *ABS*  00000000 _image_size
001c4720 g       *ABS*  00000000 _got_start
001c474c g       *ABS*  00000000 _got_end
001c4758 g       *ABS*  00000000 _edata

001c4758 g       *ABS*  00000000 __bss_start
001c475c g     O .bss   00000004 uart_base
001c4770 g     O .bss   00000004 malloc_ptr
001c4764 g     O .bss   00000004 output_ptr
001c4774 g     O .bss   00000004 malloc_count
001c476c g     O .bss   00000004 free_mem_end_ptr
001c4760 g     O .bss   00000004 output_data
001c4758 g     O .bss   00000004 __machine_arch_type
001c4768 g     O .bss   00000004 free_mem_ptr
001c4778 g       *ABS*  00000000 _end

... and I can also see it in the final zImage.

$ xxd arch/arm/boot/zImage | tail
01c4710: 221f f1b3 3ef1 1400 be52 9f58 e468 3900  "...>....R.X.h9.
01c4720: 5c47 1c00 2047 1c00 7047 1c00 e442 0000  \G.. G..pG...B..
         ^uart_base
01c4730: 6447 1c00 7447 1c00 6c47 1c00 140a 0000  dG..tG..lG......
01c4740: 6047 1c00 5847 1c00 6847 1c00 0000 0000  `G..XG..hG......
01c4750: 0000 0000 0000 0000                      ........

Surely, it's in the run-time memdump.

Before recalculation:
90563020: 001C475C 001C4720 001C4770 000042E4  001C4764 001C4774 001C476C 
00000A14
          ^uart_base
90563040: 001C4760 001C4758 001C4768 00000000  00000000 00000000 EDFE0DD0 
4C010000

After recalculation:
90563020: 905631AC 90563020 905631C0 903A2BE4  905631B4 905631C4 905631BC 
9039F314
90563040: 905631B0 905631A8 905631B8 00000000  00000000 00000000 EDFE0DD0 
4C010000

So it looks the non-static ('g') uninitialized variable sits in .bss
sections well, while static ('l') one is not there.  Is this
expected?  How the static one is being addressed?  Or ask where the
offset for static one is stored?

Any info or comments are appreciated.

-- 
Regards,
Shawn


_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Reply via email to