Device - IPAD running IOS 9.3.3 ( ARM architecture 64 bit - jailbroken)
When i try to disassemble the function , i get weird output with unrecognized instruction set such as vqrshl, svcge. How do i fix it? I would really appreciate your help.
Please see the gdb output below
gdb) disassemble
Dump of assembler code for function mach_msg_trap:
0x21f1f894 <mach_msg_trap+0>: mov r12, sp
0x21f1f898 <mach_msg_trap+4>: push {r4, r5, r6, r8}
0x21f1f89c <mach_msg_trap+8>: ldm r12, {r4, r5, r6}
0x21f1f8a0 <mach_msg_trap+12>: mvn r12, #30 ; 0x1e
0x21f1f8a4 <mach_msg_trap+16>: svc 0x00000080
0x21f1f8a8 <mach_msg_trap+20>: pop {r4, r5, r6, r8}
0x21f1f8ac <mach_msg_trap+24>: bx lr
End of assembler dump.
(gdb) break -[AntiPiracyViewController isJailbroken]
Breakpoint 1 at 0x73314
(gdb) C
Continuing.
warning: Unrecognized osabi 0 in arm_set_osabi_from_host_info
Breakpoint 1, 0x00073314 in -[AntiPiracyViewController isJailbroken] ()
(gdb) disassemble
Dump of assembler code for function -[AntiPiracyViewController isJailbroken]:
0x00073314 <-[AntiPiracyViewController isJailbroken]+0>: vqrshl.s8 <illegal reg q13.5>, q8, <illegal reg q8.5>
0x00073318 <-[AntiPiracyViewController isJailbroken]+4>: svcge 0x00032148
0x0007331c <-[AntiPiracyViewController isJailbroken]+8>: smlabteq r0, r0, r2, pc
0x00073320 <-[AntiPiracyViewController isJailbroken]+12>: adccs pc, r2, r1, asr #4
0x00073324 <-[AntiPiracyViewController isJailbroken]+16>: andeq pc, r0, r0, asr #5
0x00073328 <-[AntiPiracyViewController isJailbroken]+20>: ldrbtmi r4, [r8], #-1145
0x0007332c <-[AntiPiracyViewController isJailbroken]+24>: stmdavs r0, {r0, r3, r11, sp, lr}
0x00073330 <-[AntiPiracyViewController isJailbroken]+28>: cdp 0, 5, cr15, cr8, cr0, {0}
0x00073334 <-[AntiPiracyViewController isJailbroken]+32>: msrcs SPSR_f, r1, asr #4
0x00073338 <-[AntiPiracyViewController isJailbroken]+36>: smlabteq r0, r0, r2, pc
0x0007333c <-[AntiPiracyViewController isJailbroken]+40>: rscscs pc, r2, #268435460 ; 0x10000004
0x00073340 <-[AntiPiracyViewController isJailbroken]+44>: vmvn.i32 q10, #589824 ; 0x00090000
0x00073344 <-[AntiPiracyViewController isJailbroken]+48>: ldrbtmi r0, [r10], #-512
0x00073348 <-[AntiPiracyViewController isJailbroken]+52>: undefined instruction 0xf0006809
0x0007334c <-[AntiPiracyViewController isJailbroken]+56>: vceq.f32 q15, <illegal reg q0.5>, q6
0x00073350 <-[AntiPiracyViewController isJailbroken]+60>: vorr.i32 q9, #0 ; 0x00000000
0x00073354 <-[AntiPiracyViewController isJailbroken]+64>: strmi r0, [r4], -r0, lsl #2
0x00073358 <-[AntiPiracyViewController isJailbroken]+68>: rsbcs pc, lr, r1, asr #4
0x0007335c <-[AntiPiracyViewController isJailbroken]+72>: vmvn.i32 q10, #589824 ; 0x00090000
0x00073360 <-[AntiPiracyViewController isJailbroken]+76>: ldrbtmi r0, [r8]
0x00073364 <-[AntiPiracyViewController isJailbroken]+80>: stmdavs r0, {r0, r3, r11, sp, lr}
0x00073368 <-[AntiPiracyViewController isJailbroken]+84>: cdp 0, 3, cr15, cr12, cr0, {0}
0x0007336c <-[AntiPiracyViewController isJailbroken]+88>: undefined instruction 0xf000463f
0x00073370 <-[AntiPiracyViewController isJailbroken]+92>: strtmi lr, [r2], -r2, asr #28
0x00073374 <-[AntiPiracyViewController isJailbroken]+96>: vmax.s8 d20, d1, d5
0x00073378 <-[AntiPiracyViewController isJailbroken]+100>: vmvn.i32 d18, #2 ; 0x00000002
0x0007337c <-[AntiPiracyViewController isJailbroken]+104>: ldrbtmi r0, [r8]
0x00073380 <-[AntiPiracyViewController isJailbroken]+108>: strtmi r6, [r8], -r1, lsl #16
0x00073384 <-[AntiPiracyViewController isJailbroken]+112>: cdp 0, 2, cr15, cr14, cr0, {0}
0x00073388 <-[AntiPiracyViewController isJailbroken]+116>: strtmi r4, [r8], -r6, lsl #12
0x0007338c <-[AntiPiracyViewController isJailbroken]+120>: cdp 0, 3, cr15, cr0, cr0, {0}
0x00073390 <-[AntiPiracyViewController isJailbroken]+124>: undefined instruction 0xf0004620
0x00073394 <-[AntiPiracyViewController isJailbroken]+128>: rscslt lr, r0, #736 ; 0x2e0
0x00073398 <-[AntiPiracyViewController isJailbroken]+132>: svclt 0x00182800
0x0007339c <-[AntiPiracyViewController isJailbroken]+136>: ldcllt 0, cr2, [r0, #4]!
End of assembler dump.
Related
I'm working on a baremetal application for a Cortex M1 on an FPGA. I'm seeing a HardFault during the __libc_init_array function call during startup of my program.
It seems the problem is, during __libc_init_array, it branches to a function "_init". This _init function, however, does not return and runs off into the weeds until it hits a hardfault. I'm not sure what I'm doing wrong that the function isn't returning.
I've distilled my program down to the bare minimum with the full source code in the github link below. I also have put the CFLAGS and LDFLAGS I'm using along with the relevant disassembled functions.
I'm using GCC version "gcc-arm-none-eabi-9-2020-q2-update" from arm.com. I've also tried the newer "gcc-arm-none-eabi-10-2020-q4-major" release and the GCC included with STM32IDE with the same result.
I've compared the compilation flags in STM32CUBEIDE with mine as well, and nothing is jumping out at me, but the elf produced by STM32CUBEIDE is returning from its _init...
Any and all help is appreciated, thank you!
https://github.com/rockybulwinkle/cortex-m1-example
CFLAGS = \
-mthumb \
-march=armv6-m \
-mcpu=cortex-m0 \
-Wall \
-Wextra
-std=c11 \
-specs=nano.specs \
-O0 \
-fdebug-prefix-map=$(REPO_ROOT)= \
-g \
-ffreestanding \
-ffunction-sections \
-fdata-sections
LDFLAGS = \
-mthumb \
-march=armv6-m \
-mcpu=cortex-m0 \
-Wl,--print-memory-usage \
-Wl,-Map=$(BUILD_DIR)/$(PROJECT).map \
-T m1.ld \
-Wl,--gc-sections \
00000084 <Reset_Handler>:
/*
* This is the code that gets called on processor reset.
* To initialize the device, and call the main() routine.
*/
void Reset_Handler(void)
{
84: b580 push {r7, lr}
86: b082 sub sp, #8
88: af00 add r7, sp, #0
/* Initialize the data segment */
uint32_t *pSrc = &_etext;
8a: 4b13 ldr r3, [pc, #76] ; (d8 <Reset_Handler+0x54>)
8c: 607b str r3, [r7, #4]
uint32_t *pDest = &_sdata;
8e: 4b13 ldr r3, [pc, #76] ; (dc <Reset_Handler+0x58>)
90: 603b str r3, [r7, #0]
if (pSrc != pDest) {
92: 687a ldr r2, [r7, #4]
94: 683b ldr r3, [r7, #0]
96: 429a cmp r2, r3
98: d00c beq.n b4 <Reset_Handler+0x30>
for (; pDest < &_edata;) {
9a: e007 b.n ac <Reset_Handler+0x28>
*pDest++ = *pSrc++;
9c: 687a ldr r2, [r7, #4]
9e: 1d13 adds r3, r2, #4
a0: 607b str r3, [r7, #4]
a2: 683b ldr r3, [r7, #0]
a4: 1d19 adds r1, r3, #4
a6: 6039 str r1, [r7, #0]
a8: 6812 ldr r2, [r2, #0]
aa: 601a str r2, [r3, #0]
for (; pDest < &_edata;) {
ac: 683a ldr r2, [r7, #0]
ae: 4b0c ldr r3, [pc, #48] ; (e0 <Reset_Handler+0x5c>)
b0: 429a cmp r2, r3
b2: d3f3 bcc.n 9c <Reset_Handler+0x18>
}
}
/* Clear the zero segment */
for (pDest = &_sbss; pDest < &_ebss;) {
b4: 4b0b ldr r3, [pc, #44] ; (e4 <Reset_Handler+0x60>)
b6: 603b str r3, [r7, #0]
b8: e004 b.n c4 <Reset_Handler+0x40>
*pDest++ = 0;
ba: 683b ldr r3, [r7, #0]
bc: 1d1a adds r2, r3, #4
be: 603a str r2, [r7, #0]
c0: 2200 movs r2, #0
c2: 601a str r2, [r3, #0]
for (pDest = &_sbss; pDest < &_ebss;) {
c4: 683a ldr r2, [r7, #0]
c6: 4b08 ldr r3, [pc, #32] ; (e8 <Reset_Handler+0x64>)
c8: 429a cmp r2, r3
ca: d3f6 bcc.n ba <Reset_Handler+0x36>
}
/* Run constructors / initializers */
__libc_init_array();
cc: f000 f898 bl 200 <__libc_init_array>
/* Branch to main function */
main();
d0: f7ff ffb6 bl 40 <main>
/* Infinite loop */
while (1);
d4: e7fe b.n d4 <Reset_Handler+0x50>
d6: 46c0 nop ; (mov r8, r8)
d8: 00001370 .word 0x00001370
dc: 2000001c .word 0x2000001c
e0: 20000080 .word 0x20000080
e4: 20000000 .word 0x20000000
e8: 2000001c .word 0x2000001c
00000200 <__libc_init_array>:
200: b570 push {r4, r5, r6, lr}
202: 2600 movs r6, #0
204: 4d0c ldr r5, [pc, #48] ; (238 <__libc_init_array+0x38>)
206: 4c0d ldr r4, [pc, #52] ; (23c <__libc_init_array+0x3c>)
208: 1b64 subs r4, r4, r5
20a: 10a4 asrs r4, r4, #2
20c: 42a6 cmp r6, r4
20e: d109 bne.n 224 <__libc_init_array+0x24>
210: 2600 movs r6, #0
212: f001 f8a9 bl 1368 <_init>
216: 4d0a ldr r5, [pc, #40] ; (240 <__libc_init_array+0x40>)
218: 4c0a ldr r4, [pc, #40] ; (244 <__libc_init_array+0x44>)
21a: 1b64 subs r4, r4, r5
21c: 10a4 asrs r4, r4, #2
21e: 42a6 cmp r6, r4
220: d105 bne.n 22e <__libc_init_array+0x2e>
222: bd70 pop {r4, r5, r6, pc}
224: 00b3 lsls r3, r6, #2
226: 58eb ldr r3, [r5, r3]
228: 4798 blx r3
22a: 3601 adds r6, #1
22c: e7ee b.n 20c <__libc_init_array+0xc>
22e: 00b3 lsls r3, r6, #2
230: 58eb ldr r3, [r5, r3]
232: 4798 blx r3
234: 3601 adds r6, #1
236: e7f2 b.n 21e <__libc_init_array+0x1e>
...
Disassembly of section .init:
00001368 <_init>:
1368: b5f8 push {r3, r4, r5, r6, r7, lr}
136a: 46c0 nop ; (mov r8, r8)
Disassembly of section .fini:
0000136c <_fini>:
136c: b5f8 push {r3, r4, r5, r6, r7, lr}
136e: 46c0 nop ; (mov r8, r8)
I found my answer while drafting the question. Essentially, I needed to add KEEP directives in my linker script for "init" and "fini".
Before:
.text :
{
. = ALIGN(4);
_stext = .;
KEEP(*(.vectors .vectors.*))
*(.text .text.*)
*(.rodata .rodata*)
. = ALIGN(4);
} > rom
After:
.text :
{
. = ALIGN(4);
_stext = .;
KEEP(*(.vectors .vectors.*))
KEEP(*(.init))
KEEP(*(.fini))
*(.text .text.*)
*(.rodata .rodata*)
. = ALIGN(4);
} > rom
I'm working with Keil ARMCompiler 6.15 (armclang.exe) and I'm in doubt of the correctness of the generated assembler code.
It seems to me that the attribute 'interrupt("IRQ")' is ignored.
For me r1 and r2 should be saved on the stack, too.
When I remove the attribute 'used' my complete function is removed (optimization).
Can anyone see the mistake I made or what I've forgotten?
Originally the code was created for gcc.
Attributes used for interrupt routines:
#define INTERRUPT_PROCEDURE __attribute__((interrupt("IRQ"),used,section(".IsrSection")))
#define ISR_VARIABLE __attribute__((section(".IsrSection")))
#define FAST_SHARED_DATA __attribute__((section(".FastSharedDataSection")))
C++ Code:
uint64_t volatile FAST_SHARED_DATA systick_value = uint64_t(0);
extern "C" {
void INTERRUPT_PROCEDURE SysTick_Handler()
{
systick_value++;
}
}
Assembler Code:
0x08001280 push {r4, r6, r7, lr}
0x08001282 add r7, sp, #8
0x08001284 mov r4, sp
0x08001286 bfc r4, #0, #3
0x0800128a mov sp, r4
0x0800128c movw r0, #8192 ; 0x2000
0x08001290 movt r0, #8192 ; 0x2000
0x08001294 ldrd r1, r2, [r0]
0x08001298 adds r1, #1
0x0800129a adc.w r2, r2, #0
0x0800129e strd r1, r2, [r0]
0x080012a2 sub.w r4, r7, #8
0x080012a6 mov sp, r4
0x080012a8 pop {r4, r6, r7, pc}
0x080012aa movs r0, r0
0x080012ac movs r0, r0
0x080012ae movs r0, r0
You do not need this attribute. It is needed in very rare circumstances when the stack is not aligned to 8 bytes (STKALGN bit is not set) by the hardware and you are going to use functions with 64 bits parameters (like uint64_t). ARM automatically saves R0-R3 + some others registers on the stack when entering the ISR handler. If you use FPU you may want to enable FPU registers stackup as well.
I'm trying to debug a program on a BeagleBone Black. Outside the debugger it produces an incorrect result but no SIGILL. It also runs OK under the debugger without a breakpoint. However it produces a SIGILL with a breakpoint set when stepping. The program and library does not use SIGILL-based cpu feature probes. However, I don't know what GDB is doing.
Under the debugger I am seeing:
(gdb) b main
Breakpoint 1 at 0x26f20: file test.cxx, line 22.
(gdb) r
Starting program: /home/cryptopp/test.exe
Breakpoint 1, main (argc=0x1, argv=0xbeffea54) at test.cxx:22
22 byte key[16] = {0};
(gdb) n
23 byte iv[12] = {0};
(gdb)
25 GCM<AES>::Encryption enc;
(gdb)
26 enc.SetKeyWithIV(key, 16, iv, 12);
(gdb)
28 std::string plain(0x00, 16);
(gdb)
Program received signal SIGILL, Illegal instruction.
0x00026d5c in std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)
()
(gdb) n
Single stepping until exit from function _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_,
which has no line number information.
Program terminated with signal SIGILL, Illegal instruction.
The program no longer exists.
And:
(gdb) shell echo _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_ | c++filt
std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)
I tried searching for this issue, but I have not been able to locate a hit. I'm getting too much noise.
Why am I experiencing a SIGILL when GDB sets a breakpoint, and how do I work around it?
NEON is the problem I am trying to investigate. Here's the command line used for the program and library:
$ echo $CXXFLAGS
-DDEBUG -g3 -O0 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=hard
$ g++ $CXXFLAGS test.cxx ./libcryptopp.a -o test.exe
And:
$ gdb --version
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
$ uname -a
Linux beaglebone 4.1.15-ti-rt-r40 #1 SMP PREEMPT RT Thu Jan 7 23:32:08 UTC 2016 armv7l GNU/Linux
$ cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 2 (v7l)
BogoMIPS : 996.14
Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc08
CPU revision : 2
Hardware : Generic AM33XX (Flattened Device Tree)
Revision : 0000
Serial : 0000000000000000
And:
Breakpoint 1, main (argc=0x1, argv=0xbeffea54) at test.cxx:22
22 byte key[16] = {0};
(gdb) n
23 byte iv[12] = {0};
(gdb)
25 GCM<AES>::Encryption enc;
(gdb)
26 enc.SetKeyWithIV(key, 16, iv, 12);
(gdb)
28 std::string plain(0x00, 16);
(gdb)
Program received signal SIGILL, Illegal instruction.
0x00026d5c in std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)
()
(gdb) up
#1 0x00026f82 in main (argc=0x1, argv=0xbeffea54) at test.cxx:28
28 std::string plain(0x00, 16);
(gdb) disass
Dump of assembler code for function main(int, char**):
0x00026f10 <+0>: push {r4, r7, lr}
0x00026f12 <+2>: sub.w sp, sp, #916 ; 0x394
0x00026f16 <+6>: add r7, sp, #16
0x00026f18 <+8>: adds r3, r7, #4
0x00026f1a <+10>: str r0, [r3, #0]
0x00026f1c <+12>: mov r3, r7
0x00026f1e <+14>: str r1, [r3, #0]
0x00026f20 <+16>: add.w r3, r7, #692 ; 0x2b4
0x00026f24 <+20>: movs r2, #0
0x00026f26 <+22>: str r2, [r3, #0]
0x00026f28 <+24>: adds r3, #4
0x00026f2a <+26>: movs r2, #0
0x00026f2c <+28>: str r2, [r3, #0]
0x00026f2e <+30>: adds r3, #4
0x00026f30 <+32>: movs r2, #0
0x00026f32 <+34>: str r2, [r3, #0]
0x00026f34 <+36>: adds r3, #4
0x00026f36 <+38>: movs r2, #0
0x00026f38 <+40>: str r2, [r3, #0]
0x00026f3a <+42>: adds r3, #4
0x00026f3c <+44>: add.w r3, r7, #680 ; 0x2a8
0x00026f40 <+48>: movs r2, #0
---Type <return> to continue, or q <return> to quit---
0x00026f42 <+50>: str r2, [r3, #0]
0x00026f44 <+52>: adds r3, #4
0x00026f46 <+54>: movs r2, #0
0x00026f48 <+56>: str r2, [r3, #0]
0x00026f4a <+58>: adds r3, #4
0x00026f4c <+60>: movs r2, #0
0x00026f4e <+62>: str r2, [r3, #0]
0x00026f50 <+64>: adds r3, #4
0x00026f52 <+66>: add.w r3, r7, #240 ; 0xf0
0x00026f56 <+70>: mov r0, r3
0x00026f58 <+72>: bl 0x2a804 <CryptoPP::GCM_Final<CryptoPP::Rijndael, (CryptoPP::GCM_TablesOption)0, true>::GCM_Final()>
0x00026f5c <+76>: add.w r1, r7, #240 ; 0xf0
0x00026f60 <+80>: add.w r2, r7, #692 ; 0x2b4
0x00026f64 <+84>: add.w r4, r7, #680 ; 0x2a8
0x00026f68 <+88>: movs r3, #12
0x00026f6a <+90>: str r3, [sp, #0]
0x00026f6c <+92>: mov r0, r1
0x00026f6e <+94>: mov r1, r2
0x00026f70 <+96>: movs r2, #16
0x00026f72 <+98>: mov r3, r4
0x00026f74 <+100>: bl 0x2da0c <CryptoPP::SimpleKeyingInterface::SetKeyWithIV(unsigned char const*, unsigned int, unsigned char const*, unsigned int)>
---Type <return> to continue, or q <return> to quit---
0x00026f78 <+104>: add.w r3, r7, #708 ; 0x2c4
0x00026f7c <+108>: mov r0, r3
0x00026f7e <+110>: blx 0x26d58 <_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_+852>
=> 0x00026f82 <+114>: add.w r2, r7, #676 ; 0x2a4
0x00026f86 <+118>: add.w r3, r7, #708 ; 0x2c4
0x00026f8a <+122>: mov r0, r2
0x00026f8c <+124>: movs r1, #0
0x00026f8e <+126>: movs r2, #16
...
Thanks to #ks1322, this is a known GDB/Kernel bug. See GDB crashes on debugging multithreaded program on ARM SMP dual core system in the GDB issue tracker.
According to the Debian BTS, this is also a known issue. See SIGILL when stepping through application on armhf in the Debian BTS.
The bug was refilled in hopes that it might actually be fixed sometime in the next year or two. See GDB Crash due to GDB/Kernel generated SIGILL
This is why I despise Debian's bug reporting systems. Stuff gets reported and then it just rots. Nothing gets fixed.
I have the following source code:
const ClassTwo g_classTwo;
void ClassOne::first()
{
g_classTwo.doSomething(1);
}
void ClassOne::second()
{
g_classTwo.doSomething(2);
}
Which produces the following objdump:
void ClassOne::first()
{
1089c50: e1a0c00d mov ip, sp
1089c54: e92dd800 push {fp, ip, lr, pc}
1089c58: e24cb004 sub fp, ip, #4
1089c5c: e24dd008 sub sp, sp, #8
1089c60: e50b0010 str r0, [fp, #-16]
g_classTwo.doSomething(1);
1089c64: e59f3014 ldr r3, [pc, #20] ; 1089c80 <ClassOne::first()+0x30>
1089c68: e08f3003 add r3, pc, r3
1089c6c: e1a00003 mov r0, r3
1089c70: e3a01001 mov r1, #1
1089c74: ebffffe2 bl 1089c04 <ClassTwo::doSomething(int) const>
}
1089c78: e24bd00c sub sp, fp, #12
1089c7c: e89da800 ldm sp, {fp, sp, pc}
1089c80: 060cd35c .word 0x060cd35c
01089c84 <ClassOne::second()>:
void ClassOne::second()
{
1089c84: e1a0c00d mov ip, sp
1089c88: e92dd800 push {fp, ip, lr, pc}
1089c8c: e24cb004 sub fp, ip, #4
1089c90: e24dd008 sub sp, sp, #8
1089c94: e50b0010 str r0, [fp, #-16]
g_classTwo.doSomething(2);
1089c98: e59f3014 ldr r3, [pc, #20] ; 1089cb4 <ClassOne::second()+0x30>
1089c9c: e08f3003 add r3, pc, r3
1089ca0: e1a00003 mov r0, r3
1089ca4: e3a01002 mov r1, #2
1089ca8: ebffffd5 bl 1089c04 <ClassTwo::doSomething(int) const>
}
1089cac: e24bd00c sub sp, fp, #12
1089cb0: e89da800 ldm sp, {fp, sp, pc}
1089cb4: 060cd328 .word 0x060cd328
Both methods are loading the address of g_classTwo with a pc relative offset: ldr r3, [pc, #20], which translates to 0x060cd35c and 0x060cd328 for the first and second method respectively.
Why are the addresses different even though they are both addressing the same global variable?
How do those addresses relate to the nm output for the same symbol: 07156fcc b g_classTwo?
In ClassOne::first() you have:
1089c64: e59f3014 ldr r3, [pc, #20] ; 1089c80 <ClassOne::first()+0x30>
1089c68: e08f3003 add r3, pc, r3
1089c6c: e1a00003 mov r0, r3
...
1089c80: 060cd35c .word 0x060cd35c
In ClassOne::second() you have:
1089c98: e59f3014 ldr r3, [pc, #20] ; 1089cb4 <ClassOne::second()+0x30>
1089c9c: e08f3003 add r3, pc, r3
1089ca0: e1a00003 mov r0, r3
...
1089cb4: 060cd328 .word 0x060cd328
In both, r0 is the this pointer (g_classTwo). As you can see, after loading an address from the literal pool into r3 it is summed to pc to get r0.
In ClassOne::first(), you get r0 = pc + r3 = 0x01089c70 + 0x060cd35c = 0x07156fcc.
In ClassOne::second(), you get r0 = pc + r3 = 0x01089ca4 + 0x060cd328 = 0x07156fcc.
So for both the this pointer is 0x07156fcc, which is the address of g_classTwo.
I have a makefile that generates a shared library. Calling make from different shells (VxWorks wrenv and Cygwin) results in different libs. Thy VxWorks version is working the Cygwin version not. The differences are very small and not visible with the readelf program.
Using objdumparm -S *.so shows the difference at the end of the functions. See the following output.
Example 1: (two last line differ)
Cygwin:
00010a14 <_ZN3rag3MD511save_digestEPhPKm>:
10a14: e1a0c00d mov ip, sp
10a18: e92dda30 push {r4, r5, r9, fp, ip, lr, pc}
...
10b18: 00000000 andeq r0, r0, r0
10b1c: 3b6e71a1 blcc 1bad1a8 <_stack+0x1b2d1a8>
10b20: 505c3d7f subspl r3, ip, pc, ror sp
VxWorks:
00010a14 <_ZN3rag3MD511save_digestEPhPKm>:
10a14: e1a0c00d mov ip, sp
10a18: e92dda30 push {r4, r5, r9, fp, ip, lr, pc}
...
10b18: 00000000 andeq r0, r0, r0
10b1c: 00000338 andeq r0, r0, r8, lsr r3
10b20: 0000033c andeq r0, r0, ip, lsr r3
or Example 2: (last line differs)
Cygwin:
00010b7c <_ZN3rag3MD55beginEv>:
10b7c: e1a0c00d mov ip, sp
10b80: e92dda10 push {r4, r9, fp, ip, lr, pc}
...
10bd4: e89daa10 ldm sp, {r4, r9, fp, sp, pc}
10bd8: 00000000 andeq r0, r0, r0
10bdc: 695c7960 ldmdbvs ip, {r5, r6, r8, fp, ip, sp, lr}^
VxWorks:
00010b7c <_ZN3rag3MD55beginEv>:
10b7c: e1a0c00d mov ip, sp
10b80: e92dda10 push {r4, r9, fp, ip, lr, pc}
...
10bd4: e89daa10 ldm sp, {r4, r9, fp, sp, pc}
10bd8: 00000000 andeq r0, r0, r0
10bdc: 000005ec andeq r0, r0, ip, ror #11
The parameters for the linker are identical. Do these differences come from the relocation process?
It possible to say why this happens, the reason?
Hmm, the linker wasn't the bad guy! Found out that the compiler was generating different .sho objects. Using the -fno-builtin option to compile the .sho's did remove the differences...