similar to: can valgrind read LLD's debug info?

As a frontend, what are the downsides of enabling --no-rosegment by default? So far the pro list is: * valgrind debug info will work by default What's on the con list? On Thu, Apr 5, 2018 at 5:16 PM, Shoaib Meenai <smeenai at fb.com> wrote: > It's more of a valgrind issue than an LLD issue, but you can work around > it by linking with --no-rosegment > > > >

It's more of a valgrind issue than an LLD issue, but you can work around it by linking with --no-rosegment From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> Reply-To: Andrew Kelley <superjoe30 at gmail.com> Date: Thursday, April 5, 2018 at 2:14 PM To: LLVM Dev <llvm-dev at lists.llvm.org> Subject:

--rosegment puts read-only data and executable text in a single segment and make it executable, so your read-only code becomes executable. I think that shouldn't be a default behavior. If valgrind needs that, we can't fix it by changing the default. On Thu, Apr 5, 2018 at 2:50 PM Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Confirmed that -no-rosegment

Confirmed that -no-rosegment worked around the issue. However, a valgrind developer says that perhaps LLD is generating strange object files: <tomhughes> I suspect that is some extra ro segment in addition to the normal rodata <tomhughes> so without it you have two <tomhughes> but I know nothing about lld <tomhughes> but without an executable to examine/test it's hard

But I can't think of a reason that valgrind needs executable data segment. It is likely that valgrind assumes some specific segment layout that the GNU linker creates and can't handle other layout even if it is valid. On Thu, Apr 5, 2018 at 3:21 PM Rui Ueyama <ruiu at google.com> wrote: > --rosegment puts read-only data and executable text in a single segment > and make it

Looks like I have run into the same issue reported in: https://bugs.llvm.org/show_bug.cgi?id=20871 Is there a fix or work-around for it? The bug report seems to be still open. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/46c1282d/attachment.html>

This looks similar to the problem I fixed awhile back in r292408. I'll take a look (probably tomorrow since I am taking some vacation today). Teresa On Tue, May 16, 2017 at 9:43 AM, David Blaikie <dblaikie at gmail.com> wrote: > +Teresa > > On Mon, May 15, 2017 at 9:20 AM David Callahan via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I am tracking a

I've successfully used Peter's patches to get past those relocation errors. On 6/28/17, 9:36 AM, "llvm-dev on behalf of Peter Smith via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: Yes it should cover the following relocations: R_ARM_CALL (ARM BL/BLX) R_ARM_JUMP24 (ARM B) R_ARM_THM_CALL (Thumb BL/BLX)

At a guess that looks like your llvm and lld checkouts are not quite in synch. It will be worth updating llvm and lld to top of trunk. I've rebased the consolidated patch https://reviews.llvm.org/D34634 this morning, it might be worth trying that if you are seeing problems. Peter On 29 June 2017 at 22:09, Alessandro Pistocchi <apukfreelance at gmail.com> wrote: > Hi, I tried

The bottom of the bug has the revision numbers (e.g. D34035). That one corresponds to e.g. https://reviews.llvm.org/D34035 There's also https://reviews.llvm.org/D34634 which contains all of Peter's patches, but it's not going to rebase cleanly once the individual patches start going in. On 6/28/17, 10:56 AM, "Alessandro Pistocchi" <apukfreelance at gmail.com> wrote:

Hi everyone, The WebAssembly backend recently had Bug 39448 <https://bugs.llvm.org/show_bug.cgi?id=39448> filed against it because NaN payloads in floating-point immediates are not preserved through compilation on 32-bit builds. I took a look and the corruption takes place when the immediates are converted from APFloats to be stored as native doubles in MCOperand. I assume this bug only

I recently debugged an issue where I wasn't getting stack traces from ASAN on 32-bit ARM (on Android) when using a libclang_rt.asan-arm-android.so I'd built myself. I finally ended up tracing it to a build issue; the CMake build check for -funwind-tables was failing (because of some missing link libraries), so compiler-rt wasn't being built with that flag, which in turn led to all

I can't send the exact objects, but I'll try to reproduce. Thanks A On 11/16/20, 9:48 AM, "Fāng-ruì Sòng" <maskray at google.com> wrote: NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Mon, Nov 16, 2020 at 9:05 AM Moshtaghi, Alireza

I think the simplest, most complete, short term fix, would be to call llvm::colorEHFunclets, and to have the relevant instrumentation passes apply the appropriate funclet bundle when inserting function calls. It's not elegant because it means every simple instrumentation pass that inserts regular function calls (ASan, TSan, MSan, instrprof, etc) needs to be funclet-aware. But, it will work,

On Thu, Aug 29, 2019 at 3:10 AM Fāng-ruì Sòng <maskray at google.com> wrote: > Hello Vic, > > To make sure I understand the proposal correctly, do you propose: > > Old: R RX RW(RELRO) RW > New: R(R+RELRO) RX RW; R includes the traditional R part and the > RELRO part > Runtime (before relocation resolving): RW RX RW > Runtime (after relocation resolving): R RX

This is a common pitfall: people think that .text is the first section of the traditional concept "text segment" (which does not apply with LLD layout and GNU ld's -z separate-code layout) You need to use --image-base=0 https://releases.llvm.org/10.0.0/tools/lld/docs/ReleaseNotes.html#breaking-changes On Mon, Nov 16, 2020 at 10:31 AM Moshtaghi, Alireza <Alireza.Moshtaghi at

Oh, so it looks like I hit a bit of a wall there :-) I’ll take a look thanks. That bug talks about R_ARM_THM_CALL which I assume are thumb related. Will your implementation fix also R_ARM_CALL errors? > On 28 Jun 2017, at 17:15, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Alessandro, > > The LLD ARM port doesn't currently support range extension thunks,

On Fri, Aug 30, 2019 at 4:54 AM Fāng-ruì Sòng <maskray at google.com> wrote: > > > Old: R RX RW(RELRO) RW > > > New: R(R+RELRO) RX RW; R includes the traditional R part and the > > > RELRO part > > > Runtime (before relocation resolving): RW RX RW > > > Runtime (after relocation resolving): R RX RW > > > > > I actually see two

Hi, we at Arm have noticed that assembly can differ when compiling for AArch64 depending on whether debug information is generated or not. The issue is reproducible for the following small example compiled with `-O1` for `aarch64-arm-linux-gnu`: a() { b(a); for (;;) c("", b); } The reason for the difference is that AArch64 frame lowering emits CFI

Hello Vic, I don't have a lot to add myself. I think that majority of the input needs to come from the OS stakeholders. My main concern is if it requires work on every platform to take advantage or avoid regressions then perhaps it is worth adding as an option rather than changing the default. Some questions: - Does this need work in every OS for correctness of programs? For example you