[Bug ld/15222] Alignment of load address of data sections containing aligned data
http://sourceware.org/bugzilla/show_bug.cgi?id=15222 Terry Guo changed: What|Removed |Added CC||terry.guo at arm dot com -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15302] New: Branching to linker script symbol is resolved to improperly BLX instruction for cortex-m3
http://sourceware.org/bugzilla/show_bug.cgi?id=15302
Bug #: 15302
Summary: Branching to linker script symbol is resolved to
improperly BLX instruction for cortex-m3
Product: binutils
Version: 2.24 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: terry@arm.com
CC: joey...@arm.com
Classification: Unclassified
Host: i686
Target: cortex-m3
In C file I have a call to function extFunc which is then defined in my linker
script as a script symbol "extFunc = 0x1000 + 1;". In assembly code I got
branch instruction "bl extFunc", but in final image this instruction is
resolved to "blx 0x1000" which is illegal for cortex-m3 and will cause a
HardFault.
Should the ld consider the limitation of cortex-m3 or this is illegal usage
model? Please advise.
Here are steps to reproduce this problem.
My test.c file is:
extern void extFunc (void);
void main (void) {
extFunc ();
}
My link script file is simple as:
extFunc = 0x1000 + 1;
Command to compile the test.c is:
arm-none-eabi-gcc -mthumb -mcpu=cortex-m3 -c test.c
Command to build them together is:
arm-none-eabi-ld test.o -T link.ld
Disassemble the produced file and get:
terguo01@terry-pc01:latest$ ./install-native/bin/arm-none-eabi-objdump -d a.out
a.out: file format elf32-littlearm
Disassembly of section .text:
:
0:b580 push{r7, lr}
2:af00 addr7, sp, #0
4:f000 effc blx1000
8:bd80 pop{r7, pc}
a:bf00 nop
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15302] Branching to linker script symbol is resolved to improperly BLX instruction for cortex-m3
http://sourceware.org/bugzilla/show_bug.cgi?id=15302
--- Comment #3 from Terry Guo ---
(In reply to Nick Clifton from comment #1)
> Created attachment 6968 [details]
> Do not enable blx use on thumb-only architectures.
>
> Hi Terry,
>
> Please could you try out the uploaded patch and let me know if it works
> for you.
>
> Cheers
> Nick
Apologize for my slow response. With your patch I got code like:
terguo01@terry-pc01:case$ ../install-native/bin/arm-none-eabi-objdump -d a.out
a.out: file format elf32-littlearm
Disassembly of section .text:
:
0:b580 push{r7, lr}
2:af00 addr7, sp, #0
4:f000 f804 bl10 <__extFunc_from_thumb>
8:bd80 pop{r7, pc}
a:bf00 nop
c: movsr0, r0
...
0010 <__extFunc_from_thumb>:
10:4778 bxpc
12:46c0 nop; (mov r8, r8)
14:ea0003f9 b1000 <__extFunc_from_thumb+0xff0>
terguo01@terry-pc01:case$
It's same with Pavel's issue. Can you please continue to look into it?
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15302] Branching to linker script symbol is resolved to improperly BLX instruction for cortex-m3
http://sourceware.org/bugzilla/show_bug.cgi?id=15302 --- Comment #4 from Terry Guo --- Created attachment 7076 --> http://sourceware.org/bugzilla/attachment.cgi?id=7076&action=edit A proposal to fix this bug Hello Nick and Pavel, I am inspired by Nick's patch and managed to come up with this one. It did fixed this issue without causing any new failures in regress test. Can you guys please help to check it? Is this patch good enough to be sent to Binutils mailing list for review? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15302] Branching to linker script symbol is resolved to improperly BLX instruction for cortex-m3
http://sourceware.org/bugzilla/show_bug.cgi?id=15302 Terry Guo changed: What|Removed |Added CC||nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15628] Cortex M4 incorrect blx instruction generated
http://sourceware.org/bugzilla/show_bug.cgi?id=15628 Terry Guo changed: What|Removed |Added CC||terry.guo at arm dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15302] Branching to linker script symbol is resolved to improperly BLX instruction for cortex-m3
http://sourceware.org/bugzilla/show_bug.cgi?id=15302
Terry Guo changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed||2013-06-21
Resolution|FIXED |---
Ever confirmed|0 |1
--- Comment #7 from Terry Guo ---
I am sorry that I have to reopen it. The proposed patch will cause below issue.
In the below concrete case, the __init_array_start is allocated at address
0x11a40 actually. But any relocations using address of __init_array_start will
be resolved to use address 0x11a41 by linker, thus the subsequential deference
on __init_array_start is a deference on wrong address (0x11a41).
This is because the proposed patch set ST_BRANCH_TO_THUMB to the symbol
__init_array_start, then the last bit of its address is set by the linker
function elf32_arm_swap_symbol_out.
To reproduce this issue, an ARM baremetal toolchain using Newlib as C library
is needed. Then use below command to build a project with empty main function:
arm-none-eabi-gcc -mthumb -mcpu=cortex-m3 -O2 -lc -lrdimon -specs=rdimon.specs
test.c -o test.out -Wl,-verbose -Wl,-Map=test.map
Then run test.out on QEMU, a Segmentation falut will be reported.
qemu-system-arm -cpu cortex-m3 -nographic -monitor null -serial null
-semihosting -kernel ./test.out
This QEMU segmentation fault is caused by deference of __init_array_start in
function __libc_init_array.
Here are some investigations:
Disassemble the test.out with command "arm-none-eabi-objdump -D test.out" and
we will see:
Disassembly of section .init_array:
00011a40 <__init_array_start>:
11a40: 802dandeq r8, r0, sp, lsr #32
The __init_array_start is allocated at address 0x11a40 actually.
Meanwhile the command "arm-none-eabi-readelf -s test.out", we will get symbol
table:
222: 00011a41 0 FUNCLOCAL DEFAULT7 __init_array_start
Thus any instructions using __init_array_start will be resolved to 0x11a41
instead of 0x11a40.
movwr5, #:lower16:__init_array_start
movtr5, #:upper16:__init_array_start
ldr r3, [r5, #4]!
blx r3
in the above case, the r5 will get wrong value 0x11a41, then r3 will get wrong
value, finally the blx will cause the fault.
Here are some background on Newlib:
In Newlib init.c we have code:
extern void (*__init_array_start []) (void) __attribute__((weak));
extern void (*__init_array_end []) (void) __attribute__((weak));
void
__libc_init_array (void)
{
size_t count;
size_t i;
count = __init_array_end - __init_array_start;
for (i = 0; i < count; i++)
__init_array_start[i] ();
}
Both __init_array_start and __init_array_end are defined in linker script as:
.init_array :
{
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array ))
PROVIDE_HIDDEN (__init_array_end = .);
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15302] Branching to linker script symbol is resolved to improperly BLX instruction for cortex-m3
https://sourceware.org/bugzilla/show_bug.cgi?id=15302 Terry Guo changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Terry Guo --- Fixed by a updated patch at https://sourceware.org/ml/binutils/2013-07/msg00094.html. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
