This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Query reg. unallocated section
- To: Shankara Raman S <shankara dot raman at wipro dot com>
- Subject: Re: Query reg. unallocated section
- From: Nick Clifton <nickc at cambridge dot redhat dot com>
- Date: 02 Nov 2001 18:45:36 +0000
- Cc: Philip Blundell <pb at nexus dot co dot uk>, binutils at sources dot redhat dot com
- References: <3BDD2DF7.81A26EE3@wipro.com> <E15yA4g-0000Dw-00@mill.nexus.co.uk><3BDE0EE2.A9B20DE5@wipro.com>
Hi Shankara,
> The assembly file is:
>
> .text
> nop
> nop
> b sym
> nop
>
> .section .mynoalloc
> sym: nop
> nop
>
> .section .myalloc, "ax"
> nop
>
> I am doing the following:
>
> as file.s -o file.o
> ld file.o -Ttext 0x0 -o file (to force the .text to start at 0x0)
>
> and
>
> objdump -D file shows:
> 00000000 <.text>:
> 0: e1a00000 nop (mov r0,r0)
> 4: e1a00000 nop (mov r0,r0)
> 8: eafffffc b 0 <sym>
> c: e1a00000 nop (mov r0,r0)
> Disassembly of section .myalloc:
> The address of "sym" has been resolved to 0, which is now the
> beginning of the text section.
Right - what is wrong with that ? 0x0 is also the start of the
.mynoalloc section, so the branch is still going to "sym" at its
start.
> I am not sure if this behaviour is incorrect, but should the linker
> print a warning ?
What that a branch was attempted to a symbol located in a
non-allocated section ?
Perhaps you were thinking of a patch like this ?
Cheers
Nick
2001-11-02 Nick Clifton <nickc@cambridge.redhat.com>
* elf32-arm.h (elf32_arm_final_link_relocate): Catch attempts
to perform a pc-relative relocation against a symbol in an
unallocated section.
Index: bfd/elf32-arm.h
===================================================================
RCS file: /cvs/src/src/bfd/elf32-arm.h,v
retrieving revision 1.62
diff -c -p -r1.62 elf32-arm.h
*** elf32-arm.h 2001/10/12 11:16:21 1.62
--- elf32-arm.h 2001/11/02 18:43:38
*************** elf32_arm_final_link_relocate (howto, in
*** 1113,1118 ****
--- 1113,1126 ----
#ifndef OLD_ARM_ABI
case R_ARM_XPC25:
#endif
+ /* Branching to a symbol which is in a section which is not
+ going to exist in the executable image is a bad idea. */
+ if (sym_sec != NULL && ((sym_sec->flags & SEC_ALLOC) == 0))
+ (* _bfd_error_handler)
+ (_(
+ "Warning: PC relative relocation against symbol '%s' which is in an unallocated section!"),
+ sym_name);
+
/* When generating a shared object, these relocations are copied
into the output file to be resolved at run time. */
if (info->shared