Adjust finding arena_thread for ARM arch. for stripped GLIBC

[yooo1999]

Here we can see the calculation of thread_arena for stripped ARM GLIBC.

That code guess the section in calloc function looks like:

ldr reg1, [pc, #offset]
mrc 15, 0, reg2, cr13, cr0, {3}
add reg1, pc
ldr reg1, [reg1]
add reg1, reg2

In some GLIBC it's look different, for example armv7-eabihf--glibc--stable-2017.05-toolchains this section looks like:

ldr  R3, =0x355C
mrc p15, 0, R2,c13,c0, 3
mov  R5, R0
ldr R3, [PC,R3] ; thread_arena
ldr R4, [R2,R3]

md5sum armv7-eabihf--glibc--stable/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libc.a
#34a0cc33addd0034c14011707674d90d  

(This libc is not stripped to help this issue , but I found some stripped ARM GLIBC with that section)

Please adjust the code that we can find the thread_arena for that section too.
@lebr0nli

[lebr0nli]

Please adjust the code that we can find the thread_arena for that section too.

For this, I think with the current techniques we have, it's hard to handle it on different glibc versions and architecture with this approach, so I think a hard-coded patch to adjust the code just for this case might not be a good idea, since it will eventually fail or its result will be falsely positive in the future glibc version and make the code here dirtier and dirtier each time we try to adjust it again for another failing case.
So instead of adjusting it, in the latest commit, we provide an optional way to brute force it if all of the arenas didn't corrupt.
But it might not reliable and slow in some cases, so if the number of arenas doesn't large, I'll suggest you manually determine it and set it with set thread-arena <the address>, and it should not be too hard to find which arena your current thread using after some tests.

(I know the new method sounds stupid, but I guess it's the only thing we can do now.
If you have better ideas, or probably a way to do code simulation or something instead of only filtering the disassembly result, PR is welcome!)