scripts/addToolsVersion: properly handle .in vs. .in.2
While most components have their version in the .in file, some
have it in the .in.2 (eg. elf2flt).
Currently, to handle this case, we indiscriminately munge both files,
but this is wrong: in the elf2flt case, if we add a binutils version,
we do not want it to be added to elf2flt, and conversely.
So, for each tool, we need to explicitly know what file to munge.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
1 diff -p -c -u -r1.196 elf32-arm.c
3 diff -durN binutils-2.20.1.orig/bfd/elf32-arm.c binutils-2.20.1/bfd/elf32-arm.c
4 --- binutils-2.20.1.orig/bfd/elf32-arm.c 2010-02-22 09:06:48.000000000 +0100
5 +++ binutils-2.20.1/bfd/elf32-arm.c 2010-08-17 19:32:25.000000000 +0200
6 @@ -3194,11 +3194,15 @@
8 /* We have an extra 2-bytes reach because of
9 the mode change (bit 24 (H) of BLX encoding). */
10 + /* A stub is needed only if this call is not throught a PLT
11 + entry, because PLT stubs handle mode switching
13 if (branch_offset > (ARM_MAX_FWD_BRANCH_OFFSET + 2)
14 || (branch_offset < ARM_MAX_BWD_BRANCH_OFFSET)
15 - || ((r_type == R_ARM_CALL) && !globals->use_blx)
16 - || (r_type == R_ARM_JUMP24)
17 - || (r_type == R_ARM_PLT32))
18 + || ( (((r_type == R_ARM_CALL) && !globals->use_blx)
19 + || (r_type == R_ARM_JUMP24)
20 + || (r_type == R_ARM_PLT32))
23 stub_type = (info->shared | globals->pic_veneer)