[llvm-dev] LLD symbol types for defsym

[Shoaib Meenai via llvm-dev]

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=