Linker Bug or Design Intent (Absolute symbols in zero sized sections)

[Vivek Goyal <vgoyal at redhat dot com>]

Hi,

I got a query. Ld behaviour does not seem to be conforming to what is 
mentioned in "info ld"

I was going through the info ld and found following in the section 3.6.7 
"Output Section Discarding"

   "If you use anything other than an input section description as an
output section command, such as a symbol assignment, then the output
section will always be created, even if there are no matching input
sections."

I am compiling my kernel and I don't seem to be getting above mentioned 
behaviour. For, example vmlinux.ld.S has got following code.

  .smp_altinstructions : AT(ADDR(.smp_altinstructions) - LOAD_OFFSET) {
        __smp_alt_begin = .;
        __smp_alt_instructions = .;
        *(.smp_altinstructions)
        __smp_alt_instructions_end = .;
  }


In finally generated executable, thre is no section as 
.smp_altinstructions and symbols __smp_alt_begin, __smp_alt_instructions
and __smp_alt_instructions_end have become absolute symbols.

Looks like there was no section .smp_altinstructions present in input 
files hence linker did not create output section and made symbols 
absolute. This does not match the behaviour as stated in "info ld". Is 
this a bug or design intent?

I am using GNU ld version 2.17.50.0.3-1

HOW AM I IMPACTED:
--------------------

Now we are trying to make i386 kernel fully relocatable. We compile the 
kernel with option --emit-relocs and use this relocation information to 
relocate the kernel at run time. But as per the specifications absolute 
symbols are not to be relocated.

Now, above compiler makes some symbols absolute and these symbols are 
not relocated and kernel code fails at some point. In this case kernel 
fails because it is trying to free memory between symbol __smp_alt_begin 
and another symbol present in other section. __smp_alt_begin is now 
absolute and does not get relocated and kernel ends up trying to free a 
wrong portion of memory.

Do you have any thoughts about what's the right way of fixing the issue? 
 Its a linker bug or it should be fixed in kernel?

Thanks
Vivek