NetBSD/aarch64 Unknown relocation type for got: 299

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

NetBSD/aarch64 Unknown relocation type for got: 299

tinycc-devel mailing list
I fixed this one also. But the problem is that below commits are gone.
This happended after te commit 'arm-asm: Implement branch to label'

    Herman

commit 94714f046b423b6ee10471575082419a280ac663
Author: herman ten brugge [hidden email]
Date:   Mon Jan 4 21:22:18 2021 +0100

    text relocation for arm

commit e5c3d1dc705f4c1b4ecccf795f97fa409914ea2e
Author: herman ten brugge [hidden email]
Date:   Mon Jan 4 18:14:09 2021 +0100

    disable nan test for clang

commit 29d8871d6196819caff83b4359e22cc3655bc234
Author: Michael Matz [hidden email]
Date:   Mon Jan 4 03:58:22 2021 +0100

    Implement proper floating point negation
   
    Using "-0.0 - x" still isn't enough if x is a NaN, so bite the bullet
    and implement sign-bit flipping via memory.  (It's usually not too bad,
    the -0.0-x method also uses memory for the floating point constant).
   
    This way is at least shorter than implementing a new top-level operation
    for all backends (a negate) that would be unary.

commit 4c9516941c459ba2294c3d3f7bd3a81af33ec618
Author: herman ten brugge [hidden email]
Date:   Sun Jan 3 20:12:34 2021 +0100

    Fix wine
   
    After removing uint64_t from stddef.h the tcc_libm.h now needs to
    include stdint.h

commit 33d5a9fadb50e4163209bb27abcfe9d0ef451051
Author: herman ten brugge [hidden email]
Date:   Sun Jan 3 19:14:53 2021 +0100

    add arm64 relocs


On 1/5/21 7:06 AM, Christian Jullien wrote:

Yet another reloc error with clang, on NetBSD aarch64 this time

 

uname -a

NetBSD arm64 9.1 NetBSD 9.1 (GENERIC64) #0: Sun Oct 18 19:24:30 UTC 2020  [hidden email] evbarm

....
OK

------------ dlltest ------------

Hello World

------------ dlltest with PIC ------------

tcc: error: Unknown relocation type for got: 299

make[2]: *** [Makefile:166: dlltest] Error 1

------------ abitest-cc ------------



_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: NetBSD/aarch64 Unknown relocation type for got: 299

grischka
Herman ten Brugge via Tinycc-devel wrote:
> I fixed this one also. But the problem is that below commits are gone.
> This happended after te commit 'arm-asm: Implement branch to label

Hi Herman,

Would you consider to review the "text relocation for arm" commit,
eventually?

Such copy & paste portions not only look ugly but also make it more
difficult for other people to understand the structure and to make
changes if they want to.

Also a bit more explanation would be nice.  Does it introduce text
relocations or does it try to avoid them?  What is the benefit, under
what scenario, and is it desirable always or should it maybe depend
on a -fPIE switch or like that?

Thanks,

--- grischka


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: NetBSD/aarch64 Unknown relocation type for got: 299

grischka
Herman ten Brugge wrote:
> I just commited an update.

Thanks ;)

>> Also a bit more explanation would be nice.  Does it introduce text
>> relocations or does it try to avoid them?  What is the benefit, under
>> what scenario, and is it desirable always or should it maybe depend
>> on a -fPIE switch or like that?
>
> As far as I know all targets generate -FPIC code by default.
>
> For bsd support I recently applied patches to use the GOT table correctly.
> Also netbsd requires that DT_TEXTREL is not set. So I applied patches
> for that also.

I just wondered whether it adds some overhead that for most cases is
not really necessary when executables are loaded at fixed addresses
without need for relocations to its own symbols at runtime really.

Some systems may require position independent executables but even
GCC I think needs a configure option to make them by default.

Also there is still the ARM-PE target, aka wince.  I don't know if
it's still functional (or ever was) though.

--- grischka

> The only target that does now uses DT_TEXTREL is i386. But this requires
> a complete rewrite.
>
>     Herman


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: NetBSD/aarch64 Unknown relocation type for got: 299

tinycc-devel mailing list
On 1/7/21 10:53 PM, grischka wrote:

> Herman ten Brugge wrote:
>> I just commited an update.
>
> Thanks ;)
>
>>> Also a bit more explanation would be nice.  Does it introduce text
>>> relocations or does it try to avoid them?  What is the benefit, under
>>> what scenario, and is it desirable always or should it maybe depend
>>> on a -fPIE switch or like that?
>>
>> As far as I know all targets generate -FPIC code by default.
>>
>> For bsd support I recently applied patches to use the GOT table
>> correctly.
>> Also netbsd requires that DT_TEXTREL is not set. So I applied patches
>> for that also.
>
> I just wondered whether it adds some overhead that for most cases is
> not really necessary when executables are loaded at fixed addresses
> without need for relocations to its own symbols at runtime really.
>
> Some systems may require position independent executables but even
> GCC I think needs a configure option to make them by default.
>
> Also there is still the ARM-PE target, aka wince.  I don't know if
> it's still functional (or ever was) though.
>
I first bench marked the code before committing. The slowdown was
between 2% and 5% depending on how much global data is used.
I also saw that incrementing a variable in global memory does
2 times a pointer load.
So:

int a;
int main(void) { a++; return 0; }

results in arm code:

00000000 <main>:
    0:   e1a0c00d        mov     ip, sp
    4:   e92d5800        push    {fp, ip, lr}
    8:   e1a0b00d        mov     fp, sp
    c:   e1a00000        nop                     ; (mov r0, r0)
   10:   e59fe000        ldr     lr, [pc]        ; 18 <main+0x18>
   14:   ea000000        b       1c <main+0x1c>
   18:   fffffff4                        ; <UNDEFINED> instruction:
0xfffffff4
   1c:   e08ee00f        add     lr, lr, pc
   20:   e59ee000        ldr     lr, [lr]
   24:   e59e0000        ldr     r0, [lr]
   28:   e1a01000        mov     r1, r0
   2c:   e2800001        add     r0, r0, #1
   30:   e59fe000        ldr     lr, [pc]        ; 38 <main+0x38>
   34:   ea000000        b       3c <main+0x3c>
   38:   fffffff4                        ; <UNDEFINED> instruction:
0xfffffff4
   3c:   e08ee00f        add     lr, lr, pc
   40:   e59ee000        ldr     lr, [lr]
   44:   e58e0000        str     r0, [lr]
   48:   e3a00000        mov     r0, #0
   4c:   e89ba800        ldm     fp, {fp, sp, pc}

The lr register loaded at line 24 is not reused and is fetched again.
If this for example is fixed the slowdown would be much less.
>> The only target that does now uses DT_TEXTREL is i386. But this requires
>> a complete rewrite.
I made some simple patches to the i386 code but quickly came to the
conclusion that converting this target is not feasible.
So I will not update this target.

     Herman


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel