similar to: [LLVMdev] LLD: representation of a power of two value

On Tue, Mar 24, 2015 at 5:40 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Mar 24, 2015, at 5:09 PM, Rui Ueyama <ruiu at google.com> wrote: > > > 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.

I guess I'm talking about atoms. Do we have notion of section in LLD? On Wed, Mar 25, 2015 at 8:35 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > On 3/24/2015 7:51 PM, Rui Ueyama wrote: > >> On Tue, Mar 24, 2015 at 5:40 PM, Nick Kledzik <kledzik at apple.com> wrote: >> >> On Mar 24, 2015, at 5:09 PM, Rui Ueyama <ruiu at google.com>

I submitted a series of patches to convert all uses of log2 values to non-log2 values (That was harder than I thought because the types of the two are the same. They only different in meaning. So it was not easy to distinguish them. I split up patches so that anyone can verify correctness of the conversion that I've done.) >From now on, please always use non-log2 alignment values

On Fri, Feb 6, 2015 at 5:42 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Fri, Feb 6, 2015 at 5:31 PM, Rui Ueyama <ruiu at google.com> wrote: > > There are two questions. > > > > Firstly, do you think the on-disk format needs to compatible with a C++ > > struct so that we can cast that memory buffer to the struct? That may be > >

I think no one is opposing the idea of reading and writing YAML. The problem here is that why we need to force all developers to write code to serialize intermediate data in the middle of link, which no one except the round-trip passes needs. On Fri, Feb 6, 2015 at 6:41 PM, Shankar Easwaram <shankarke at gmail.com> wrote: > Doing it for every input file is not useful as some of the

Not all input files have to be able to represented in YAML/Native format. There are many unrealistic use cases there. No one wants to write an executable file in Native because there's no operating system that can run that file. So is YAML. So is the combination of .so file and Native/YAML unless we have an operating system whose loader is able to loads a YAML .so file. We might want to write

There are two questions. Firstly, do you think the on-disk format needs to compatible with a C++ struct so that we can cast that memory buffer to the struct? That may be super-fast but that also comes with many limitations. It's hard to extend, for example. Every time we want to store variable-length objects we need to define string-table-like data structure. And I'm not very sure that

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

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

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

Can we remove Native format support? I'd like to get input from anyone who wants to keep the current Native format in LLD. On Thu, Feb 5, 2015 at 2:03 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > The only way currently is to create a new reference, unless we can think > of adding some target specific metadata information in the Atom model. > > This has come up

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

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

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

Shankar and I discussed input file handling, and we came up with a design that may greatly simplify the input file handling, while giving more flexibility to developer to support complicated options, such as --{start,end}-group, -z rescan or -z rescan-now. It'd worth pursuing, so here's the idea: 1. We wouldn't probably want to let Resolver to handle the input graph directly, for we

On Thu, Mar 6, 2014 at 2:21 PM, Craig Topper <craig.topper at gmail.com> wrote: > It also doesn't do pure methods either. I think I don't quite understand what that means. Can you give me an example? > On Thursday, March 6, 2014, Rui Ueyama <ruiu at google.com> wrote: > >> After running the tool aginst LLD, I realized that clang-modernize do not >> add

On Mon, Oct 6, 2014 at 5:00 PM, Nick Kledzik <kledzik at apple.com> wrote: > On Oct 6, 2014, at 3:44 PM, Rui Ueyama <ruiu at google.com> wrote: > > Looks like most people in this thread support using LLVM style in LLD. I > also had an offline discussion and many people wanted to have one coding > style in all LLVM projects. So I'm convinced that we should do that.

Looks like most people in this thread support using LLVM style in LLD. I also had an offline discussion and many people wanted to have one coding style in all LLVM projects. So I'm convinced that we should do that. I'm going to create a patch to rename all variables if no one objects. On Mon, Oct 6, 2014 at 3:10 PM, Bruce Hoult <bruce at hoult.org> wrote: > On Tue, Oct 7, 2014

Yes, it's very likely. It'd be very convenient if we could send a patch to buildbots for testing without actually submitting. On Thu, Jul 18, 2013 at 4:38 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Thu, Jul 18, 2013 at 4:29 PM, Rui Ueyama <ruiu at google.com> wrote: > > Hi LLVMdev, > > > > My recent commit r186623 caused buildbots for

Judging by this path: needed by 'tools/lld/Common/VCSVersion.inc' It looks to me like this is **not** a monorepo layout (if it were, lld would not appear in the tools directory). Therefore the LLVM_ENABLE_PROJECTS=lld is not even doing anything. I don't know how to build without a monorepo these days, and I also don't know what the most recent guidance setting up a monorepo is,