CODEWITHSUNDEEP
gccassemblycompilationarm
Bill Randerson
Bill Randerson

Reputation: 1088

When will gcc generate <UNDEFINED> instructions for function

I recently run into a SEGV_MAPPER fault, caused by fault addr 0xfffffab8. But there is no place that this address is being called explicitly. So I dumped so library using arm-linux-androideabi-objdump, and find a couple of places in functions like:

000a42f8 <std::__1::basic_ostream<char, std::__1::char_traits<char> >::~basic_ostream()>:
   a42f8:       4b08            ldr     r3, [pc, #32]   ; (a431c <std::__1::basic_ostream<char, std::__1::char_traits<char> >::~basic_ostream()+0x24>)
   a42fa:       4a09            ldr     r2, [pc, #36]   ; (a4320 <std::__1::basic_ostream<char, std::__1::char_traits<char> >::~basic_ostream()+0x28>)
   a42fc:       447b            add     r3, pc
   a42fe:       b510            push    {r4, lr}
   a4300:       4604            mov     r4, r0
   a4302:       589a            ldr     r2, [r3, r2]
   a4304:       4907            ldr     r1, [pc, #28]   ; (a4324 <std::__1::basic_ostream<char, std::__1::char_traits<char> >::~basic_ostream()+0x2c>)
   a4306:       320c            adds    r2, #12
   a4308:       6022            str     r2, [r4, #0]
   a430a:       585b            ldr     r3, [r3, r1]
   a430c:       f103 0108       add.w   r1, r3, #8
   a4310:       f840 1f04       str.w   r1, [r0, #4]!
   a4314:       f7c3 ee80       blx     68018 <std::__1::ios_base::~ios_base()@plt>
   a4318:       4620            mov     r0, r4
   a431a:       bd10            pop     {r4, pc}
   a431c:       7758            strb    r0, [r3, #29]
   a431e:       0024            movs    r4, r4
   a4320:       fabc ffff                       ; <UNDEFINED> instruction: 0xfabcffff
   a4324:       fab8 ffff                       ; <UNDEFINED> instruction: 0xfab8ffff

Apparently, this issue is caused by accessing these undefined instructions. So my question is that why gcc is generating these undefined instructions and when these instructions will be accessed? Is it like some sort of protection generated by compiler? Thank you guys.

Upvotes: 1

Views: 1539

Answers (1)

Carl Norum
Carl Norum

Reputation: 224944

Normally those instructions aren't instructions at all; they're either inline data used by the function or just padding emitted by the compiler or linker to keep function/method addresses correctly aligned. Either way, they're never executed unless you have a bad jump somewhere (broken function pointer, for example).

NB - in your case, they're both the inline data type; check the PC-relative accesses made at a42f8, a42fa, and a4304.

Upvotes: 5

Related Questions