similar to: [LLVMdev] LLD: Returning true on success

On Tue, Sep 24, 2013 at 12:33 PM, Rui Ueyama <ruiu at google.com> wrote: > Hi LLD developers, > > I'm about to make a change to invert the return value of Driver::parse() > to return true on success. Currently it returns false on success. > > In many other functions, we return true to indicate success and false to > indicate failure. The inconsistency is confusing,

On 9/24/2013 2:33 PM, Rui Ueyama wrote: > Hi LLD developers, > > I'm about to make a change to invert the return value of > Driver::parse() to return true on success. Currently it returns false > on success. You have to be a bit careful here, as the return from parse is used as a exit code from lld. The Unix shell interprets 0 (false as success) as 1(true as failure). It

On Sep 24, 2013, at 12:40 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Tue, Sep 24, 2013 at 12:33 PM, Rui Ueyama <ruiu at google.com> wrote: > Hi LLD developers, > > I'm about to make a change to invert the return value of Driver::parse() to return true on success. Currently it returns false on success. > > In many other functions, we return true

On Sep 24, 2013, at 4:07 PM, Sean Silva <chisophugis at gmail.com> wrote: > On Tue, Sep 24, 2013 at 4:17 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Sep 24, 2013, at 12:40 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > >> On Tue, Sep 24, 2013 at 12:33 PM, Rui Ueyama <ruiu at google.com> wrote: >> Hi LLD developers, >>

On Tue, Sep 24, 2013 at 4:17 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Sep 24, 2013, at 12:40 PM, Michael Spencer <bigcheesegs at gmail.com> > wrote: > > On Tue, Sep 24, 2013 at 12:33 PM, Rui Ueyama <ruiu at google.com> wrote: > >> Hi LLD developers, >> >> I'm about to make a change to invert the return value of Driver::parse()

On Tue, Sep 24, 2013 at 4:44 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Sep 24, 2013, at 4:07 PM, Sean Silva <chisophugis at gmail.com> wrote: > > On Tue, Sep 24, 2013 at 4:17 PM, Nick Kledzik <kledzik at apple.com> wrote: > >> >> On Sep 24, 2013, at 12:40 PM, Michael Spencer <bigcheesegs at gmail.com> >> wrote: >> >>

Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> writes: > - LLVM's `/*foo=*/`-style comment to annotate function arguments need > to be handled automatically to make the tool scalable. So is the > doxygen @parameter. This is a bit of a side note, but in my own work I've more recently tried to move from this style: foo.h int foo(int a, bool doSomething); foo.cpp

David Blaikie <dblaikie at gmail.com> writes: > Why would enums be less elegant than named boolean constants as you've shown here? Casting, mainly. If the parameters were also changed to an enum type that would be fine too, probably better than inline variables even. > http://jlebar.com/2011/12/16/Boolean_parameters_to_API_functions_considered_harmful..html > (at a random

Could you elaborate a bit about the issue that you are trying to solve with this suggestion? On Tue, Apr 1, 2014 at 9:27 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Nick, Bigcheese, > > Resurrecting a old thread. > > Now since we have a Registry that models Readers, do we want to have a > function in the Registry that evaluates whether a file should be

Hi Nick, Bigcheese, When lld is used to link C++ code, it would be required to demangle symbol names by default/user driven option. The Gnu linker has the following options :- --demangle=[style] --no-demangle I found that clang/llvm-symbolizer use __cxx_demangle function. I would think that lld also need to call the same function, and I think the way we want to demangle is to have the

On Tue, Sep 24, 2013 at 6:07 PM, Sean Silva <chisophugis at gmail.com> wrote: > I think it makes a lot of sense in this case. The idea is that you > increase indentation in the "error" case. I vehemently disagree. Use the return value and type that make sense for the ABI and will be unsurprising when reading the code. Use a ! when you need to produce early-exit code

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

Good point, too. I believe I can find lines starting with `@parameter` and apply the same name conversion rules to identifiers after `@parameter`. Since lld doesn't use doxygen comments, it is fine for now, but before moving forward, I'll address that. Thank you for pointing that out. On Wed, Jul 10, 2019 at 8:20 PM Alex Brachet-Mialot < alexbrachetmialot at gmail.com> wrote: >

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>

On 10/7/2013 3:23 PM, Nick Kledzik wrote: > On Oct 4, 2013, at 8:50 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: >> It is needed that lld verifies the input to the linker. >> >> For example : a x86 ELF file can be given to lld when the target is x86_64. Similiarly with other flavors. >> >> I was thinking to have a varargs function in the

On 4/2/2014 12:23 PM, Nick Kledzik wrote: > On Apr 1, 2014, at 9:19 PM, Shankar Easwaran wrote: > >> Hi Nick, Bigcheese, >> >> When lld is used to link C++ code, it would be required to demangle symbol names by default/user driven option. >> >> The Gnu linker has the following options :- >> >> --demangle=[style] >> --no-demangle >>

# is a line comment chracter in YAML so it's valid. That's why I wrote a simple magic "comment". On Thu, Oct 10, 2013 at 6:21 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 10/10/2013 5:00 PM, Rui Ueyama wrote: > >> On Thu, Oct 10, 2013 at 9:16 AM, Shankar Easwaran >> <shankare at codeaurora.org>**wrote: >> >> On

Thank you for quick responses! As to dead stripping, if dead stripping is the only pass we need bi-directional edges, we might want the dead stripping pass to construct internal data structure by reversing the graph to construct layout-before edges from layout-after edges. This should be less error prone than maintaining two reverse-directional edges throughout all passes. Of course it will make

So I talked with Shankar on IRC on this topic, and here's a suggestion. 1. Use a magic comment to determine if it's a YAML file. I'd propose "#!obj" as a YAML file magic because of similarity of Unix shebang. YAML reader skips this first line because it's a comment line in YAML grammar. 2. Add "target" field to YAML to represent what machine type the object

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.