similar to: lld: --start-lib and --end-lib

Displaying 20 results from an estimated 10000 matches similar to: "lld: --start-lib and --end-lib"

2017 Oct 26
4
[RFC] Making .eh_frame more linker-friendly
Hi, There will be problems with eh_frame_hdr. Eh_frame_hdr is needed to use the binary search instead of the linear search. Having eh_frame per a function will cause no eh_frame_hdr or multiple eh_frame_hdr and will degrade search from binary to linear. As we create eh_frame_hdr in most cases there is no problem to filter out garbage eh_frame sections. If there is information about unused
2017 Oct 26
4
[RFC] Making .eh_frame more linker-friendly
No I haven't. Thank you for the pointer. Looks like the problem of the inverted edges was discussed there. But I guess my bigger question is this: why do we still create one big .eh_frame even if -ffunction-sections is given? When the option is given, Clang creates .text, .rela.text and .gcc_exception_table sections for each function, but it still creates a monolithic .eh_frame that covers
2017 Feb 14
2
RFC: A new llvm-dlltool driver and llvm-lib driver improvements
Yes, that would be the long term plan. llvm-link ideally would share the same library. I'm not sure where it should live though. On Tue 14 Feb 2017 at 01:49, Rui Ueyama <ruiu at google.com> wrote: > I took a look at the code. Looks like you need a library to create import > library files in LLVM and use that from llvm-dlltool and LLD. Is that what > you are planning? > >
2017 May 03
2
Help with setting up ARM embedded clang + lld
On 2 May 2017 at 23:59, Rui Ueyama <ruiu at google.com> wrote: > That's interesting. Usually your code wouldn't be gc'ed because your entire > code is reachable from _start. Baremetal doesn't need a _start. > Does your program depend on the feature that, if no -e option is given, the > linker sets the beginning of the .text section to the entry point address?
2017 Feb 14
3
RFC: A new llvm-dlltool driver and llvm-lib driver improvements
Well that means it would just be the only plan then. I assume the first step would be to move the code from lld into this new library and lld can use that? I can then re add the extra functionality for weak externals? We can then have lib and dlltool use this then. On Tue 14 Feb 2017 at 01:58, Rui Ueyama <ruiu at google.com> wrote: > On Mon, Feb 13, 2017 at 5:56 PM, Martell Malone
2017 Feb 14
2
RFC: A new llvm-dlltool driver and llvm-lib driver improvements
Ohh nice. With that method I can support it without upsetting ld users by introducing an api breakage. On Tue 14 Feb 2017 at 01:32, Rui Ueyama <ruiu at google.com> wrote: > On Mon, Feb 13, 2017 at 5:26 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > On Mon, Feb 13, 2017 at 5:20 PM, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >
2017 Feb 14
2
RFC: A new llvm-dlltool driver and llvm-lib driver improvements
On Mon, Feb 13, 2017 at 5:20 PM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Feb 13, 2017 at 4:46 PM, Martell Malone <martellmalone at gmail.com> > wrote: > >> No, I meant an even thinner wrapper which textually translates arguments. >>> For example, the wrapper would translates "/out:foo.exe foo.obj" to "-o
2016 Nov 17
2
LLD: time to enable --threads by default
The current implementation was “copy/pasted” from somewhere (it was explicitly public domain). > On Nov 16, 2016, at 4:05 PM, Rui Ueyama <ruiu at google.com> wrote: > > Can we just copy-and-paste optimized code from somewhere? > > On Wed, Nov 16, 2016 at 4:03 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > SHA1 in LLVM is
2019 Feb 28
4
lld-link crash when linking intrinsics lib
+Peter Collingbourne <pcc at chromium.org> LTO is used in this test case, and one source file defines its own `memset` function while the other file uses llvm.memset. Looks like LTO is confused by the user-defined memset. Could you take a look? Steven, Do you need to use LTO? I thought that LTO is a workaround to not produce an object file that cannot be handled by your ELF-to-COFF
2018 Jan 08
2
Linker Option support for ELF
On Mon, Jan 8, 2018 at 3:22 AM, Peter Smith <peter.smith at linaro.org> wrote: > On 8 January 2018 at 09:32, James Henderson via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > On 8 January 2018 at 08:14, Rui Ueyama <ruiu at google.com> wrote: > >> > >> On Mon, Jan 8, 2018 at 3:55 AM, Sean Silva via llvm-dev > >> <llvm-dev at
2017 Feb 14
2
RFC: A new llvm-dlltool driver and llvm-lib driver improvements
> > No, I meant an even thinner wrapper which textually translates arguments. > For example, the wrapper would translates "/out:foo.exe foo.obj" to "-o > foo.exe foo.obj" and then call lld::COFFF:link(). It doesn't do anything > with Config object nor LinkerDriver::run and have absolutely zero knowledge > on the internals of LLD. Ohh okay I misunderstood.
2017 Feb 13
2
RFC: A new llvm-dlltool driver and llvm-lib driver improvements
> > I wonder if it can be a wrapper for LLD/COFF. It can be an in-process > wrapper, meaning that you could add a main function for mingw which > translates all arguments into the MSVC style and then invoke the COFF > linker's main function. That should work, if I am understanding this correctly I can create an argument parser (probably partially based on the ELF one) then I
2014 Mar 07
2
[LLVMdev] [RFC] C++11: 'virtual' and 'override'
On Thu, Mar 6, 2014 at 3:47 PM, Craig Topper <craig.topper at gmail.com> wrote: > virtual bar *foo() = 0; > > where foo() also exists as pure in the base class. Clang-modernize has a > FIXME that says it can't find the "=0" to do the insert of override. > Does that mean we have a pure virtual function with implementation in Clang/LLVM? If so, I feel it's a
2016 Mar 21
2
Need help with code generation
On Mon, Mar 21, 2016 at 8:25 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > > Also, if it can segfault for some pathetic input > > Surely that's a bug though, not seriously designed behaviour? > No. That is a design choice. > On Mon, 21 Mar 2016 at 19:24 Rui Ueyama <ruiu at google.com> wrote: > >> We do not enable exceptions and longjmp is not
2015 Jul 14
7
[LLVMdev] New linker ownership
The new linker is quickly becoming more than just an experiment. 64-bit COFF linker is mostly feature complete, and now we are having a direct translation of the COFF linker for ELF. Historically LLD has been suffered by over-designing and over-engineering. I don't want to repeat that again in the new codebase, so I'd like to be an owner of the new linkers (both for ELF and COFF), so that
2015 Mar 25
7
[LLVMdev] LLD: representation of a power of two value
It's not a big deal, but it always annoyed me a bit when I hit it, so I'll bring it up here. LLD represents an alignment X as log2(X) in some places and just X in other places. It's a bit confusing. Because I always think alignments in my mind in terms of 1, 2, 4, 8, ..., instead of 2^1, 2^2, 2^3, ..., I'd like to propose to always use real values. Any objections? --------------
2015 May 27
4
[LLVMdev] LLD improvement plan
On 26 May 2015, at 20:13, Rui Ueyama <ruiu at google.com> wrote: > > I sent a patch to llvm-commits. You can see the code at http://reviews.llvm.org/D10036. Thanks! Why does the link not actually go where the text of it would imply, and instead bounce via some random (malicious?) third party? Do you have some malware infecting your mail client? David
2017 Feb 13
2
RFC: A new llvm-dlltool driver and llvm-lib driver improvements
> > Also you need to make a change to LLD/COFF to accept GNU command > arguments, right? (Looks like you already have that patch locally.) Yes > My patch to hack lld into accepting some very basic gnu front end > arguments was enough to get all the above working which was enough to > develop further. On Mon, Feb 13, 2017 at 8:41 PM, Rui Ueyama <ruiu at google.com>
2019 Jun 24
4
Expected behavior of lld during LTO for global symbols (Attr Internal/Common)
The direct cause of this issue is that, previously lld converted common symbols to defined symbols before passing input files to LTO, and after r360841 they are passed as common symbols to LTO. Making lld to work as before is easy, as we can convert common symbols to defined symbols as before. Here is a patch to do that, and I confirmed that that restores the original behavior for the reported
2015 Apr 09
2
[LLVMdev] LLD: Removing Native file format?
I sent a patch for review. I'll wait for a while, probably submit that tomorrow. On Thu, Apr 9, 2015 at 2:14 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Thu, Apr 9, 2015 at 12:17 PM, Rui Ueyama <ruiu at google.com> wrote: > > I think I bought up this topic before, but I'd like to propose seriously > > removing the Native file format from LLD this