Stefan =?utf-8?q?Gränitz?=
Message-ID:
In-Reply-To:
MaskRay wrote:
I just noticed that non-arm architectures have a `HAVE_LINKER_FLAG_LONG_PLT`
check. This is an arm ELF specific option in GNU ld (ignored by lld). You could
keep the previous architecture == ARM check so that other machines d
weliveindetail wrote:
The above patch landed after `release/18.x` branched. It drops the check for
`CMAKE_SYSTEM_PROCESSOR` as discussed in this thread and only relies on the
linker-flag check.
This seems to be the right thing to do. I checked on 32-bit Raspbian @ RPi4b:
It correctly defaults
weliveindetail wrote:
I was wondering as well and checked the codebase for existing uses, but no
findings. Yes, clang has no JIT and may not reach the limit. And yes, LLDB is
mostly an `.so` where the linker's approach might differ and/or it's just not
built frequently for ARM. Myself, I usual
mstorsjo wrote:
> > I don't really know more about the issue that requires --long-plt at the
> > moment and why it's only needed for clang-repl
>
> clang-repl binary size is ~3.7G in debug mode and this seems to exceed the
> branch range of default ARM PLT slots. The instruction sequence that'
weliveindetail wrote:
> I don't really know more about the issue that requires --long-plt at the
> moment and why it's only needed for clang-repl
clang-repl binary size is ~3.7G in debug mode and this seems to exceed the
branch range of default ARM PLT slots. The instruction sequence that's
n
mstorsjo wrote:
> Oh, I usually don't do that, but it's certainly a valid point. Can you think
> of a better way to express the condition here? We need `-Wl,--long-plt` for
> ARM targets whenever the used linker supports it. Otherwise we have to assume
> that it emits such PLTs by default.
No
weliveindetail wrote:
Oh, I usually don't do that, but it's certainly a valid point. Can you think of
a better way to express the condition here? We need `-Wl,--long-plt` for ARM
targets whenever the used linker supports it. Otherwise we have to assume that
it emits such PLTs by default.
http
mstorsjo wrote:
> > When cross compiling LLVM, I never have set `CMAKE_SYSTEM_PROCESSOR` so
> > far, since we don't really have anything that uses it (before this), which
> > means that this expands to an empty string. I guess I should set it still
> > though.
>
> Yes, I am just getting used
weliveindetail wrote:
CMake does always have more surprises to offer :) Thanks for fixing it right
away @mstorsjo!
> When cross compiling LLVM, I never have set `CMAKE_SYSTEM_PROCESSOR` so far,
> since we don't really have anything that uses it (before this), which means
> that this expands t
Stefan =?utf-8?q?Gr=C3=A4nitz?=
Message-ID:
In-Reply-To:
shiltian wrote:
> @shiltian Does that fix the issue for you?
Yes, thanks!
https://github.com/llvm/llvm-project/pull/78959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
weliveindetail wrote:
@shiltian Does that fix the issue for you?
https://github.com/llvm/llvm-project/pull/78959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Stefan =?utf-8?q?Gränitz?=
Message-ID:
In-Reply-To:
shiltian wrote:
> Oh, that's unfortunate. Let me add a check for `LLVM_USE_LINKER=gold`. AFAIK
> it's never used on macOS.
It might be better to check linker flag
(https://cmake.org/cmake/help/latest/module/CheckLinkerFlag.html).
https://
weliveindetail wrote:
Oh, that's unfortunate. Let me add a check for `LLVM_USE_LINKER=gold`. AFAIK
it's never used on macOS.
https://github.com/llvm/llvm-project/pull/78959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org
Stefan =?utf-8?q?Gränitz?=
Message-ID:
In-Reply-To:
shiltian wrote:
This breaks the build on macOS because the linker doesn't support `--long-plt`.
Please fix it or revert the patch.
https://github.com/llvm/llvm-project/pull/78959
___
cfe-commits m
https://github.com/weliveindetail closed
https://github.com/llvm/llvm-project/pull/78959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
weliveindetail wrote:
Thank for the quick review! Toolchain files seem to set a lowercase string
sometimes, so I added a case-conversion.
https://github.com/llvm/llvm-project/pull/78959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://l
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/78959
From 0449f8fc14a703aae515db1696bbbee578914629 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Sat, 20 Jan 2024 11:13:45 +0100
Subject: [PATCH 1/2] [clang-repl] Fix linker error on AR
https://github.com/vgvassilev approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/78959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Stefan Gränitz (weliveindetail)
Changes
I cross-compile clang-repl with GCC-10 on Ubuntu 20.04 and get this error when
linking with gold: PLT offset too large, try linking with --long-plt
---
Full diff: https://github.com/llvm/llvm-projec
https://github.com/weliveindetail created
https://github.com/llvm/llvm-project/pull/78959
I cross-compile clang-repl with GCC-10 on Ubuntu 20.04 and get this error when
linking with gold: PLT offset too large, try linking with --long-plt
From 0449f8fc14a703aae515db1696bbbee578914629 Mon Sep 17
20 matches
Mail list logo