similar to: [LLVMdev] defined in discarded section `.gnu.linkonce.t...

On Oct 29, 2013, at 9:52 PM, Shankar Easwaran wrote: > I am trying to implement support for handling section groups in lld. > > There are two ways of figuring out section groups with ELF. > > a) Sections with SHF_GROUP property > b) .gnu.linkonce sections (the signature identified by the name of the section) -- This was the method to coalesce similiar constants. > >

On 10/30/2013 12:53 AM, Nick Kledzik wrote: > On Oct 29, 2013, at 9:52 PM, Shankar Easwaran wrote: >> I am trying to implement support for handling section groups in lld. >> >> There are two ways of figuring out section groups with ELF. >> >> a) Sections with SHF_GROUP property >> b) .gnu.linkonce sections (the signature identified by the name of the section)

Hi Nick, I am trying to implement support for handling section groups in lld. There are two ways of figuring out section groups with ELF. a) Sections with SHF_GROUP property b) .gnu.linkonce sections (the signature identified by the name of the section) -- This was the method to coalesce similiar constants. Section Groups(SHF_GROUP) is the preferred way on ELF but .gnu.linkonce sections is

Hi Nick, Bigcheese, I wanted to add support to support .gnu.linkonce sections in the resolver. _*About .gnu.linkonce sections*_ .gnu.linkonce sections were primarily present in ELF that was used in a way to model COMDAT in early ELF implementations. We have seen usecases of .gnu.linkonce sections used in various object files(mainly libc), and I think its much needed to support this style in

Before I go writing a bug report, I want to know if the behavior I am seeing is intended. Before 1.3, I was able to generate a linkonce definition in one module, and an external declaration in another module and link them together, with the result being a defined symbol with external linkage. However, with the latest head, it apparently discards the linkonce version, and my output contains

http://llvm.org/docs/LangRef.html#linkage-types says: Globals with “linkonce” linkage are merged with other globals of the same name when linkage occurs. This can be used to implement some forms of inline functions, templates, or other code which must be generated in each translation unit that uses it, but where the body may be overridden with a more definitive definition later. Unreferenced

On Jun 9, 2008, at 7:13 PM, Talin wrote: > Before I go writing a bug report, I want to know if the behavior I am > seeing is intended. > > Before 1.3, I was able to generate a linkonce definition in one > module, > and an external declaration in another module and link them together, > with the result being a defined symbol with external linkage. However, > with the

On Tue, Oct 24, 2017 at 9:27 PM, Vedant Kumar <vsk at apple.com> wrote: > Unreferenced linkonce globals are allowed to be discarded. > > > Is __udivmodti4 referenced? > It's referenced by a different .o file, but nothing within the module. My confusion comes from the missing direct object in the sentence. Referenced by a function local to the module? Referenced by any

Hi, Currently if the linker encounters a pair of linkonce function definitions with different types, it raises an error of the form: llvm-ld: error: Cannot link file 'item.o.bc': Function '_ZN18st_select_lex_unit12first_selectEv' defined as both ' %struct.SELECT_LEX* (%struct.SELECT_LEX_UNIT*)' and ' %struct.SELECT_LEX* (%struct.SELECT_LEX_UNIT*)'

On Jun 12, 2008, at 11:56 PM, Nathan Keynes wrote: > Hi, > > Currently if the linker encounters a pair of linkonce function > definitions with different types, it raises an error of the form: > > llvm-ld: error: Cannot link file 'item.o.bc': Function > '_ZN18st_select_lex_unit12first_selectEv' defined as both ' > %struct.SELECT_LEX*

On 20/06/2008, at 3:30 PM, Chris Lattner wrote: > > On Jun 12, 2008, at 11:56 PM, Nathan Keynes wrote: > >> Hi, >> >> Currently if the linker encounters a pair of linkonce function >> definitions with different types, it raises an error of the form: >> >> llvm-ld: error: Cannot link file 'item.o.bc': Function >>

Hi, I've had problem with a program using LLVM that tried to dynamic_cast objects created in the JIT execution engine, from the native part of the program (for the curious, the program is PinaVM http://gitorious.org/pinavm/pages/Home). I've narrowed down the issue to the linkage of weak_odr and linkonce_odr symbols, used for the vtables, and that _must_ be unique for dynamic_cast to

On Tue, Mar 11, 2014 at 12:17 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > I think LLVM needs new IR to represent these semantics properly. > Cool! This proposal makes a lot of sense to me. > > - Sections have linkage, all Values inside of a section must agree with > the > > section's linkage. > > This seems way too restrictive and I

I'm using LLVM 2.8 with GNU Binutils for Ubuntu 2.20.51-system.20100908. When I try to assemble a .s file generated with llc with g++ I get the error: Fatal error: duplicate .debug_line sections. I'm using llvm-gcc/g++ as front end. I also tried generating the .o file directly using -filetype=obj but that too fails with BFD: BFD (GNU Binutils for Ubuntu) 2.20.51-system.20100908

Hi All ! I have some windows-maked dll (xxx.dll for example). I want to use it on my Linux machine in my Java application. For this purpose I wrote a small wrapper around the xxx.dll by using winelib library and make it as libxxx.dll.so. Now I need load this library in my jvm (by using System.loadLibrary("xxx.dll"); ) but when I try to call any function from it I got

Hi, currently syslinux fails to build from source in Debian as has been reported in https://bugs.debian.org/906414 . The reported error is: mbr.bin: too big (452 > 440) I've realized that this is because since a recent version, the linker adds a new section (.note.gnu.property). Discarding this section fixes the problem. I've attached a patch, please consider merging it. Thanks

On Sat, Aug 18, 2018 at 11:35 AM Lukas Schwaighofer via Syslinux <syslinux at zytor.com> wrote: > currently syslinux fails to build from source in Debian as has been > reported in https://bugs.debian.org/906414 . The reported error is: > > mbr.bin: too big (452 > 440) > > > I've realized that this is because since a recent version, the linker > adds a new

Hi, Gene Cumm wrote: > > There's 0 need to build MBRs for EFI Ady wrote: > At least gptmbr.bin might come to mind It's source code looks like a BIOS MBR program which shall search the "active" partition in GPT rather than in the MBR partition table. See comments about "EBIOS" detection and "CHS" addresses in

> There's 0 need to build MBRs for > EFI At least gptmbr.bin might come to mind (after all, GPT is part of the UEFI specs). Isohybrid with UEFI options perhaps too? > and I'm looking at why utils/ depends on mbr/ isohybrid(.pl) and mkdiskimage come to mind here? I'm not saying for certain these are the reasons for such dependencies, but they might (and perhaps

> It's source code looks like a BIOS MBR program which shall search > the "active" partition in GPT rather than in the MBR partition table. > See comments about "EBIOS" detection and "CHS" addresses in > https://github.com/geneC/syslinux/blob/master/mbr/gptmbr.S > > "Active" partitn would be the one which has bit 2 set in the