Oops, I meant https://llvm.org/PR46970
On 8/3/20, 12:10 PM, "llvm-dev on behalf of Shoaib Meenai via
llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at
lists.llvm.org> wrote:
Thanks! Filed
https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_PR46790&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=7jjG6bMwk1Ta1XBsJJQQ0fvMtNG5iMUzu1jQgWNYU5A&s=TK4kKfNA82adXMrVEYv0zhcg2kZPZiQhsaVCSjgYoaw&e=
On 8/3/20, 11:57 AM, "Peter Smith" <Peter.Smith at arm.com>
wrote:
>I recognize this is hard to do in the general case, where you can
have e.g. arithmetic being performed in the defsym, but in this particular case,
it would seem desirable for the alias symbol to have the same type for the
target.
> My question is if this will end up making any difference in
practice. The case I'm concerned about in particular is ARM-Thumb
interworking, where I believe there might be some logic that's based on
symbol types.
> Is there any possibility that we'll have issues with that logic
because of the alias not being marked as a function symbol?
Thanks for pointing that out. There can be a problem on Arm as no
interworking will be performed for symbols that are not STT_FUNC. Given that
ld.bfd does preserve the symbol type for aliases I think this is worth raising a
PR.
To extend your example with:
$ cat h.c
extern void f();
extern void g();
void h() { f(); g(); }
$ clang --target=armv7a-none-eabi -c f.c
$ clang --target=armv7a-none-eabi -c h.c -mthumb
$ ld.lld f.o h.o --defsym g=f # No --shared to prevent a PLT entry.
$ objdump -d a.out
000200e4 <f>:
200e4: e12fff1e bx lr
000200e8 <h>:
200e8: b580 push {r7, lr}
200ea: 466f mov r7, sp
200ec: f7ff effa blx 200e4 <f>
200f0: f7ff fff8 bl 200e4 <f>
200f4: bd80 pop {r7, pc}
The blx to f() is correct as a state change is required. The bl to f()
will likely crash the program.
ld.bfd correctly marks g as STT_FUNC so it gets the state change correct
for both calls.
00008000 <f>:
8000: e12fff1e bx lr
00008004 <h>:
8004: b580 push {r7, lr}
8006: 466f mov r7, sp
8008: f7ff effa blx 8000 <f>
800c: f7ff eff8 blx 8000 <f>
8010: bd80 pop {r7, pc}
________________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of
Shoaib Meenai via llvm-dev <llvm-dev at lists.llvm.org>
Sent: 03 August 2020 19:23
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] LLD symbol types for defsym
I noticed that LLD doesn’t preserve the symbol type for a defsym
directive. For example:
$ cat f.c
void f() {}
$ clang -c f.c
$ ld.lld -shared --defsym=g=f f.o
$ objdump -T a.out
DYNAMIC SYMBOL TABLE:
00000000000012a0 g DF .text 0000000000000006 f
00000000000012a0 g D .text 0000000000000000 g
f is marked as a function symbol, but g is not.
I recognize this is hard to do in the general case, where you can have
e.g. arithmetic being performed in the defsym, but in this particular case, it
would seem desirable for the alias symbol to have the same type for the target.
My question is if this will end up making any difference in practice. The case
I'm concerned about in particular is ARM-Thumb interworking, where I believe
there might be some logic that's based on symbol types. Is there any
possibility that we'll have issues with that logic because of the alias not
being marked as a function symbol?
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIF-g&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=JEb_ZlzU-PlvtJQ_GhNFmjqoqRzPN5RRyItOWb9fPpo&s=SK3GezgXJpNHj933Fym67WDJdR9zXj582HJEDJLg09w&e=
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=7jjG6bMwk1Ta1XBsJJQQ0fvMtNG5iMUzu1jQgWNYU5A&s=K9_aEkIkL54ztxBufb63eORE3fI7wxHeI7BzUd9k-Qc&e=