similar to: [ELF] Symbol-ordering-file warnings

On Mon, Jan 22, 2018 at 2:00 AM, James Henderson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > > > In our proprietary linker, we have a switch which has essentially > identical functionality to the --symbol-ordering-file LLD switch. One of > the main areas that it differs in is that our linker warns in various > circumstances, if there is a problem with

Hi, When running my own lld generated library/executable I'm getting: LD_LIBRARY_PATH=. ./ConsoleApplication347 ./ConsoleApplication347: symbol lookup error: ./ConsoleApplication347: undefined symbol: (theres nothing after undefined symbol) How can I figure out what's I'm doing wrong? Full log: https://gist.github.com/carlokok/1dd510a16e1922271b520f1c00b14656 readelf -s for

On 2017-02-21 20:33, Rafael Avila de Espindola wrote: >> Input files: >> https://www.dropbox.com/s/8yn3dggx05atn47/binLinux.zip?dl=0 > > If you pass --reproduce foo.tar to lld it will create a foo.tar file > with all that is needed to reproduce the link. > > Can you also share how you created the various .o files? If so I might > be able to try reducing the issue.

I'd like to convert the following call A at GDPLT //R_HEX_GD_PLT_B22_PCREL to call __tls_get_addr //R_HEX_B22_PCREL "A" is a TLS variable and preceding code has prepared for the call. When the R_HEX_GD_PLT_B22_PCREL is found it will initially point to the TLS variable so at that point I'd like to define a __tls_get_addr symbol and update the relocation's type and symbol

Sean Silva <chisophugis at gmail.com> writes: >> When __libc_start_main is hidden, it doesn't end up in the dynamic symbol >> table and so we use the default DynsymIndex of 0. >> > > > I think BFD is doing the right thing. The `extern_weak hidden` is resolved > to null since by virtue of being hidden it doesn't refer to the function in > libc.so (and

On Tue, Feb 21, 2017 at 2:05 PM, Rafael Avila de Espindola via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Carlo Kok <ck at remobjects.com> writes: > > > On 2017-02-21 20:33, Rafael Avila de Espindola wrote: > >>> Input files: > >>> https://www.dropbox.com/s/8yn3dggx05atn47/binLinux.zip?dl=0 > >> > >> If you pass --reproduce

Rafael, here is a repro.tar to look at: https://reviews.llvm.org/F3100177 The attached foo.diff adds a print which shows the issue. ``` NAME: sleep SYMINDEX: 2 NAME: sched_yield SYMINDEX: 1 NAME: __libc_start_main SYMINDEX: 0 ``` `readelf --relocs` Shows that we create : ... 000000255110 002900000007 R_X86_64_JUMP_SLO 0000000000254410 __xstat at GLIBC_2.2.5 + 0 000000255118 001e00000007

Rafael, did you ever get a chance to look at this? -- Sean Silva On Thu, Feb 23, 2017 at 1:14 AM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Wed, Feb 22, 2017 at 6:14 AM, Rafael Avila de Espindola < > rafael.espindola at gmail.com> wrote: > >> Sean Silva <chisophugis at gmail.com> writes: >> >> When __libc_start_main is hidden, it

Hi, I was doing some experiments with LLD and noticed that it pads out OutputSections with null bytes in all cases (as far as I could tell). However, for executable sections on some targets, 0x00 forms part of an executable instruction that is not nop. In particular, for x86_64 targets at least, the sequence 0x00 0x00 is an add instruction. This can result in confusing disassembly. For example,

Hi, For MIPS it is possible that output executable file contains both GOT entry and R_MIPS_COPY or R_MIPS_REL32 relocation for the same target symbol. If LLD processes the relocation requires GOT entry before the relocation requires COPY dynamic relocation, it generates the correct output. If the order is reversed, LLD emits COPY dynamic relocation only and does not generate a GOT entry (or shows

This is really unfortunate. I've read the discussion threads for the atom/chunk controversy and I feel like I understand the reasons for rewriting the linker, but this does not seem to have anything to do with whether the linker is usable as a library or not. As it stands, not only does lld have two completely different linkers (I'm treating COFF/ELF2 as one since they are really two

Hi, Currently lld ties up all atoms in a section for ELF together. This proposal just breaks it by handling it differently. *This requires **NO ELF ABI changes. *_*Definitions :-*_ A section is not considered safe if there is some code that appears to be present between function boundaries (or) optimizes sections to place data at the end or beginning of a section (that contains no symbol).

Hello! I would like to know if there is a simple way to reorder levels of a given factor.Let's say that the vector testf<-factor(c("red","red","red","blue","blue","white")) levels(testf) : blue red white should have reordered levels such as levels(testf) : red blue white (this is for presentation purposes) I guess

Debuginfo folks, What is your opinion on this proposal? Do we need to work on better DWARFLinker library for now? or Can we start to integrate llvm-dwarfutil as a series of small patches? If it is OK to start integrating of llvm-dwarfutil, Is it OK to move llvm-objcopy implementation into separate library ObjCopy ? Thank you, Alexey. On 01.09.2020 20:18, James Y Knight wrote: > > >

On Thu, Jan 21, 2016 at 6:10 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > On 21 January 2016 at 04:11, Rui Ueyama <ruiu at google.com> wrote: > > We have fairly large and complex code to handle relocations in > Writer.cpp, > > Target.cpp, OutputSections.cpp and InputSections.cpp. They started with > > simple code, but because each patch added

Hello, My IT department has implemented a samba PDC and now we are taking flack for it. Can anyone help me out with some good justifications for doing it this way vs the Microsoft way? Have a meeting about it in a short while... We wanted to do it because Linux is more secure and more stable. But there may be other good reasons and it would be good to know them. Or maybe it would be better

I am hoping for some advice regarding ordering a dataframe, by date. The dataframe is in the format below. $story $datepub story10 1 April 1999 story 90 1 March 2002 story 37 10 July 1985 I want to reorder the entire dataframe so the earliest story is first, and save the reordered dataframe. The command, 'class' (datepub) reveals $datepub is a factor variable. I tried

(Adding back Cc: which got dropped) > (Igor - I don't know what happened, but your email split the mail thread in gmail for me.) The problem is that https://lists.llvm.org/pipermail/llvm-dev/2020-November/146528.html does not have an In-Reply-To: header. Added Igor to the Cc: list. If we go down the route (sorting DWARF64 after DWARF32), compared with a lightweight parse, I'd prefer

Thanks for your very detailed analysis. From other email conversations, it looks like -ffunction-sections and -fdata-sections are doing what is being iterated in the original proposal. On 7/31/2013 5:38 AM, Richard Osborne wrote: > I'd like to see a more precise definition of "safe". For example just > from the above description it is not clear that "safe"

On Wed, Nov 11, 2020 at 12:55 AM James Henderson <jh7370.2008 at my.bristol.ac.uk> wrote: > > > > On Wed, 11 Nov 2020 at 05:41, David Blaikie <dblaikie at gmail.com> wrote: >> >> +James for context too (always good to include the folks from the >> original threads for continuity) >> >> Yeah, my general attitude there was just twofold, one that