Some ARM-HF PLT stubs identified at wrong address

[udiboy1209]

Description

I have a binary compiled for ARMHF that contains PLT stubs to math library function log.
When I load the binary with cle and use the find_plt_stub_name function, it does not identify the stub at the address that objdump shows.

In the below disassembly, the stub is at 0x518 but cle maps it to 0x51c, which means it probably mis-identifies the start of the stub.
I tracked down the issue to the MetaELF._load_plt function, whose comments say that this is essentially performed by machine code pattern matching. I have not tried understanding the implementation of _load_plt but it looks like the pattern I have in my binary is not captured.

For now, I am checking both addr and addr+4 to find the plt stub name, and it works fine.

This plt stub is called from a tail-call optimized function. I guess this is why it has extra instructions, but I am not sure of this.

Disassembly from objdump:

...
0000050c <__stack_chk_fail@plt>:
 50c:   e28fc600        add     ip, pc, #0, 12
 510:   e28cca10        add     ip, ip, #16, 20 ; 0x10000
 514:   e5bcfabc        ldr     pc, [ip, #2748]!        ; 0xabc

00000518 <log@plt>:
 518:   4778            bx      pc
 51a:   e7fd            b.n     518 <log@plt>
 51c:   e28fc600        add     ip, pc, #0, 12
 520:   e28cca10        add     ip, ip, #16, 20 ; 0x10000
 524:   e5bcfab0        ldr     pc, [ip, #2736]!        ; 0xab0

00000528 <__gmon_start__@plt>:
 528:   e28fc600        add     ip, pc, #0, 12
 52c:   e28cca10        add     ip, ip, #16, 20 ; 0x10000
 530:   e5bcfaa8        ldr     pc, [ip, #2728]!        ; 0xaa8
...

Steps to reproduce the bug

Github wont let me attach the ELF binary. I am attaching the full disassembly from objdump.
myfunc.txt.

Let me know if you need anything else.

Environment

cle version is 9.2.86

Additional context

No response