similar to: GC for defsym'd symbols in LLD

On Wed, 4 Dec 2019 at 07:05, Fāng-ruì Sòng <maskray at google.com> wrote: > > On Tue, Dec 3, 2019 at 7:02 PM Shoaib Meenai via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > LLD treats any symbol referenced from a linker script as a GC root, which makes sense. Unfortunately, it also processes --defsym as a linker script fragment internally, so all target

I have made some further investigation. My conclusion is that GNU ld does not do better than lld. Making the --defsym behavior ideal is difficult in the current framework. GNU ld has some unintended behaviors. ld.bfd a.o --defsym 'd=foo' --gc-sections -o a => GNU ld retains .text_foo ld.bfd a.o --defsym 'd=foo+3' --gc-sections -o a => GNU ld drops .text_foo ld.bfd a.o

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

Michael Johnson <mpj at rowley.co.uk> writes: > Hi Rafael, >> Michael Johnson via llvm-dev <llvm-dev at lists.llvm.org> writes: >> >>> Hi Rui, >>> >>> Are there any plans to support the -defsym command line option? >> It doesn't look that hard, it was just never requested. What project is >> using it? > Not sure I understand

Hi Rui, I still fail to enable the lld in my Uefi firmware build to replace ld, and I found it is related to the wrong symbol values in the .data section, which are pointed by R_X86_64_64 relocation entries. I need your advices. My firmware uses a linker script https://github.com/tianocore/edk2/blob/master/BaseTools/Scripts/GccBase.lds to do the linking. We use position independent code with

Hi Nick, I am planning to work on adding support for definining expressions for the Gnu flavor. Currently Gnu ld supports an option --defsym symbol=expression. The expression may be composed of other symbols. Any symbol that appears in the expression, gets its value from the output symbol value (address of the symbol in the output file). In addition the symbol only gets defined if and only

Michael Johnson via llvm-dev <llvm-dev at lists.llvm.org> writes: > Hi Rui, > > Are there any plans to support the -defsym command line option? It doesn't look that hard, it was just never requested. What project is using it? Cheers, Rafael

On Fri, Aug 23, 2013 at 4:54 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Nick, > > Thanks for your reply. > > > On 8/23/2013 3:40 PM, Nick Kledzik wrote: > >> >> These are the changes I plan to make, and some questions that I have >> >> a) Define a new contentType for DefinedAtoms to say 'Expression' >> b) Create a

On Thu, Aug 22, 2013 at 12:54 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Nick, > > I am planning to work on adding support for definining expressions for the > Gnu flavor. > > Currently Gnu ld supports an option --defsym symbol=expression. The > expression may be composed of other symbols. > Any symbol that appears in the expression, gets its value

Hi Nick, This would work only if an alias is another name for the same symbol(weak symbols). If what is being aliased is another function definition, which is a non zero sized atom, aliasing will not work. I was thinking to model this for ELF for the below functionalities :- a) __wrap For example : --wrap fn What I plan to do here is, create a undefined function fn atom create a defined

On Wed, Jan 2, 2013 at 2:53 PM, Nick Kledzik <kledzik at apple.com> wrote: > The SECTION and MEMORY seem doable in lld as part of the ELF > Writer. MEMORY and most aspects of SECTIONS are effectively syntax sugar and the rest of LLD doesn't need to even be aware of it; the ldscript language processor will desugar it. The same is true of many other linker script constructs that I

On 14/07/2020 03:27, David Blaikie via llvm-dev wrote: > (+Richard - it's handy to include folks from previous discussions > explicitly so everyone can more easily keep track of the conversation) > > On Mon, Jul 13, 2020 at 6:17 PM Fangrui Song via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Sometimes it is

On Jan 2, 2013, at 5:51 PM, Sean Silva wrote: >> The one tricky part will be if the linker script defines symbols >> (e.g. __text_size), because those symbol names might be >> referenced by some object file atom. Thus they need an atom >> representation for lld's Resolver to see. So, the ELF Writer will need >> to make a first pass at the linker script and make

On Jan 6, 2013, at 2:05 PM, Sean Silva wrote: > but since the script can define symbols, it has to be parsed earlier. It is more than just defining symbols. There are many other directives that have command line option equivalents that are used to setup linking. You can pull symbols with EXTERN, add other files to link with INPUT, add groups of archives to be searched with GROUP, name the

Hi All, I have a design question of how your linker would be suitable for modeling ELF semantics. The ELF linker needs the functionality of reading relocations ahead of symbol resolution for the following usecases :- - Add linker defined symbols if there is a relocation to the symbol (Examples are : defsym, PROVIDE) - Dont halt the linker operation if there are undefined symbols but they are

Hi Nick, On 8/27/2013 12:45 AM, Nick Kledzik wrote: > On Aug 26, 2013, at 10:20 PM, Shankar Easwaran wrote: >> Can we add deadStrip() to undefinedAtoms as well ? >> >> This will enable to choose whether we want to set the property deadStripNormal or deadStripNever on them. >> >> Also I think it will be cleaner for atoms to be added to deadStripRoot set using a

Dear all: I am trying to compile syslinux on my machine. It's a Linux From Scratch build, pure 64 x86_64 with uClibc, using kernel 2.6.26.5, gcc 4.3.2 and binutils 2.18.0. The compile fails at the following command: make[1]: Entering directory `/home/lfs/src/pkgs/syslinux/syslinux-3.72/gpxe' make -C src EMBEDDED_IMAGE=../../core/pxelinux.0 bin/undionly.kpxe make[2]: Entering directory

Hi, All I have a problem to reuse mcjit jitted code loaded from ObjectCache from a file. In the first run, I use MCJIT generate function JittedOpExpr object code as following and it runs OK. 0x7fe4801fa1f8 at instruction 0x00007fe4cc6c2014 points to 0x69382E which is the beginning of ExecEvalVar function. Then I save the object code into a file after implementing notifyObjectCompiled method.

Hi Rui, > but why don't you use lld-link (lld for Windows target) instead of ld.lld (lld for Unix target) to create UEFI applications? I need support both PE/COFF and ELF format tools. I’m also working on the lld-link enabling (clang-cl + lld-link) in both Linux and windows. The ld.lld enabling (clang + ld.lld) is for ELF format native users. E.g.

You can't use mov. I am not an x86 expert, but after quick googling: Recall that immediates are normally restricted to 32 bits. To load a larger constant into a quad register, use movabsq, which takes a full 64-bit immediate as its source [https://www.lri.fr/~filliatr/ens/compil/x86-64.pdf] Even in your example, assembler replaces mov by movq, which, say, hints: