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=