Skip to content

ARM: compressed: clean up section layout and enable EFI debugging

Russell King - ARM Linux linux-arm-kernel 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest4 of 6 patches 0 repliesNew

4 of 6 patches are in this archive. The cover letter announces 6.

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/6ARM: compressed: move sharpsl startup code into subroutine+0 -01 reply
1/6ARM: compressed: move sharpsl startup code into subroutine+0 -00 replies
2/6ARM: compressed: move sa1100 startup code into subroutine+0 -00 replies
3/6ARM: compressed: move xscale startup code into subroutine+0 -00 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 0/6] ARM: compressed: clean up section layout and enable EFI debugging
Quoted 34 lines · Ard Biesheuvel
Quoted 32 lines · Russell King - ARM Linux
Quoted 11 lines · Ard Biesheuvel

Currently, the decompressor section layout is somewhat unusual: head.S puts code into a .start and a .text section, which are expected to be emitted back to back, unless other objects are included that define a .start section as well, in which case execution is expected to proceed linearly from head.S's section .start section into the other .start section and then onward into head.S's .text section.

This relies on the input files to be consumed by the linker in the same order they were specified on the command line, but this is not actually guaranteed by the linker, so it is better to make the inclusion of this code specific by using function calls.

I think you're wrong about that - as I've pointed out, this behaviour is relied upon quite heavily when linking programs using GCC, so while it may not be explicitly specified, the fact that GCC relies upon it when creating shared libraries (using crti.o before any object files, and crtn.o at the end) means that it's pretty much guaranteed.

What is less guaranteed is proceeding between two sections, but these separate sections in object files are combined into one .text section in the output file, and so we know that code in .start will be present _before_ any code in .text.

Put the two things together, and the code from head.S will be listed first, and therefore will be output first in the .start and .text sections. Other object files will have code placed into the output .text section accordingly.

So really I see no point to your patch 1 to 5, other than change for change's sake.

Quoted 6 lines
Quoted 3 lines

Can you _prove_ that there is a problem here - if you can, it's likely that such a problem also affects gcc -shared too.

As I replied in the other patch, GCC's builtin linker script uses SORT_NONE(), and probably does so for a reason.

To disregard any command line section sorting option that may be supplied by the user. That is not the case here. Please read the LD manual, specifically the "Input Section Wildcards" section.

Thanks.

Signature · 3 lines
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Read the cover letter in its thread