Page MenuHomePhabricator

bd1976llvm (ben)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 18 2017, 9:47 AM (130 w, 1 d)

Recent Activity

Jun 12 2019

bd1976llvm committed rG52d3e4b4aa52: [Legacy LTO] Fix build bots: r363140: Fix export name (authored by bd1976llvm).
[Legacy LTO] Fix build bots: r363140: Fix export name
Jun 12 2019, 5:16 AM
bd1976llvm committed rL363151: [Legacy LTO] Fix build bots: r363140: Fix export name.
[Legacy LTO] Fix build bots: r363140: Fix export name
Jun 12 2019, 5:16 AM
bd1976llvm committed rG564d248ec2f2: [ThinLTO]LTO]Legacy] Fix dependent libraries support by adding querying of the… (authored by bd1976llvm).
[ThinLTO]LTO]Legacy] Fix dependent libraries support by adding querying of the…
Jun 12 2019, 4:06 AM
bd1976llvm committed rL363140: [ThinLTO]LTO]Legacy] Fix dependent libraries support by adding querying of the….
[ThinLTO]LTO]Legacy] Fix dependent libraries support by adding querying of the…
Jun 12 2019, 4:05 AM
bd1976llvm closed D62935: [ThinLTO][LTO][Legacy] Fix dependent libraries support by adding querying of the IRSymtab.
Jun 12 2019, 4:05 AM · Restricted Project

Jun 11 2019

bd1976llvm added a comment to D62935: [ThinLTO][LTO][Legacy] Fix dependent libraries support by adding querying of the IRSymtab.

Thanks. I was not sure if the new functions in LTOModule.h/.cpp were in the right file - but I don't see a better place to put them.

This is fine. Do you think you might want to query symbols from InputFile instead of LTOModule in the future?

Jun 11 2019, 1:03 AM · Restricted Project

Jun 10 2019

bd1976llvm added a comment to D62935: [ThinLTO][LTO][Legacy] Fix dependent libraries support by adding querying of the IRSymtab.

We should look at either merging the implementations or providing an api function that provides access to the "llvm.linker.options" named metadata via the IRSymtab. It may not be possible to merge the implementations because in COFF and MACHO the representation of dependent libraries is a string of command line options; whereas, the ELF representation is an array of library strings. This is because for COFF and MACHO there is basically only one linker for each file format so the command line format is fixed. For ELF there are a greater variety of linkers, so I just pass the library strings through to the linker, without processing them into command line arguments, and it is deferred to the linker to interpret the library strings.

It would be good if the API is flexible to return either. Not against having a different API to return linker options but I think that is less clean.

Jun 10 2019, 6:11 PM · Restricted Project

Jun 7 2019

bd1976llvm added a comment to D62935: [ThinLTO][LTO][Legacy] Fix dependent libraries support by adding querying of the IRSymtab.

Thanks for the response.

Jun 7 2019, 5:24 PM · Restricted Project
bd1976llvm retitled D62935: [ThinLTO][LTO][Legacy] Fix dependent libraries support by adding querying of the IRSymtab from [LTO][Legacy] Fix dependent libraries support by adding querying of the IRSymtab to [ThinLTO][LTO][Legacy] Fix dependent libraries support by adding querying of the IRSymtab.
Jun 7 2019, 2:43 AM · Restricted Project

Jun 5 2019

bd1976llvm created D62935: [ThinLTO][LTO][Legacy] Fix dependent libraries support by adding querying of the IRSymtab.
Jun 5 2019, 4:45 PM · Restricted Project

May 21 2019

bd1976llvm added a comment to D62090: [runtimes] Support ELF dependent libraries feature.

Great to see someone wanting to use this. During the RFC we decided not to set SHF_EXCLUDE on the .deplibs ELF section that is used to store the strings from these pragmas. This means that other linkers that don't support dependent libraries will not remove the sections and they will end up in the output. This shouldn't cause any functional issues; however, it might be noticed by developers and commented on. Perhaps we should change this decision? Also, have you considered the other option of having the build system invoke the clang with the --dependent-library=<specifier> switch. This is an alternative approach where modifying the source code is not appropriate, an example use is: https://reviews.llvm.org/D61742.

May 21 2019, 12:48 PM · Restricted Project

May 16 2019

bd1976llvm committed rL360984: [ELF] Implement Dependent Libraries Feature.
[ELF] Implement Dependent Libraries Feature
May 16 2019, 8:44 PM
bd1976llvm committed rG1d16515fb407: [ELF] Implement Dependent Libraries Feature (authored by bd1976llvm).
[ELF] Implement Dependent Libraries Feature
May 16 2019, 8:44 PM
bd1976llvm committed rC360984: [ELF] Implement Dependent Libraries Feature.
[ELF] Implement Dependent Libraries Feature
May 16 2019, 8:44 PM
bd1976llvm committed rLLD360984: [ELF] Implement Dependent Libraries Feature.
[ELF] Implement Dependent Libraries Feature
May 16 2019, 8:43 PM
bd1976llvm closed D60274: [ELF] Implement Dependent Libraries Feature.
May 16 2019, 8:43 PM · Restricted Project

May 9 2019

bd1976llvm committed rG3edca1ac1aea: [LLD][NFC] Refactor: BuildID hash size now computed in one place. (authored by bd1976llvm).
[LLD][NFC] Refactor: BuildID hash size now computed in one place.
May 9 2019, 1:07 AM
bd1976llvm committed rLLD360316: [LLD][NFC] Refactor: BuildID hash size now computed in one place..
[LLD][NFC] Refactor: BuildID hash size now computed in one place.
May 9 2019, 1:06 AM
bd1976llvm committed rL360316: [LLD][NFC] Refactor: BuildID hash size now computed in one place..
[LLD][NFC] Refactor: BuildID hash size now computed in one place.
May 9 2019, 1:06 AM
bd1976llvm closed D61078: [LLD][NFC] Refactor: BuildID hash size calculation is now done in a single place..
May 9 2019, 1:06 AM · Restricted Project

May 1 2019

bd1976llvm committed rG6e32dd6cfd0a: [LLD] Emit dynamic relocations for references to script symbols in -pie links (authored by bd1976llvm).
[LLD] Emit dynamic relocations for references to script symbols in -pie links
May 1 2019, 7:06 AM
bd1976llvm committed rLLD359683: [LLD] Emit dynamic relocations for references to script symbols in -pie links.
[LLD] Emit dynamic relocations for references to script symbols in -pie links
May 1 2019, 7:05 AM
bd1976llvm committed rL359683: [LLD] Emit dynamic relocations for references to script symbols in -pie links.
[LLD] Emit dynamic relocations for references to script symbols in -pie links
May 1 2019, 7:05 AM

Apr 30 2019

bd1976llvm added a comment to D55423: [LLD][ELF] - A fix for "linker script assignment loses relative nature of section" bug..

@grimar - this patch causes a regression in behaviour for references to script symbols. I think https://reviews.llvm.org/D61298 is a reasonable fix. Could you take a look?

Apr 30 2019, 2:52 AM · Restricted Project
bd1976llvm created D61298: [LLD] Emit dynamic relocations for references to script symbols in -pie links.
Apr 30 2019, 2:45 AM · Restricted Project

Apr 25 2019

bd1976llvm updated the diff for D61078: [LLD][NFC] Refactor: BuildID hash size calculation is now done in a single place..

Addressed review comments

Apr 25 2019, 5:30 PM · Restricted Project
bd1976llvm added a comment to D60274: [ELF] Implement Dependent Libraries Feature.

I am keen to keep this moving.

Apr 25 2019, 4:55 PM · Restricted Project

Apr 24 2019

bd1976llvm created D61078: [LLD][NFC] Refactor: BuildID hash size calculation is now done in a single place..
Apr 24 2019, 10:14 AM · Restricted Project

Apr 16 2019

bd1976llvm updated the diff for D60274: [ELF] Implement Dependent Libraries Feature.

No longer shortening "dependent libraries" to "deplibs" except for the .deplibs section (as this takes up bytes on disk).

Apr 16 2019, 5:54 PM · Restricted Project
bd1976llvm added inline comments to D60555: [llvm-objcopy] Fill .symtab_shndx section correctly.
Apr 16 2019, 10:28 AM · Restricted Project

Apr 15 2019

bd1976llvm added a comment to D60421: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.

LGTM! Thanks for waiting for me to confirm. Comments inline:

Apr 15 2019, 2:01 PM · Restricted Project

Apr 12 2019

bd1976llvm added a comment to D60421: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.

Sorry for the delay in replying. I was trying to understand if the upgrade path was important. Comments inline:

Apr 12 2019, 1:52 PM · Restricted Project

Apr 10 2019

bd1976llvm added a comment to D60421: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.

Hi Steven,

Apr 10 2019, 8:25 AM · Restricted Project

Apr 9 2019

bd1976llvm added inline comments to D60274: [ELF] Implement Dependent Libraries Feature.
Apr 9 2019, 11:07 AM · Restricted Project
bd1976llvm added a comment to D60274: [ELF] Implement Dependent Libraries Feature.

I have updated the diff to address review comments. I think we can continue to refine this patch in parallel with discussing the design further (I am not dismissing the concerns raised by @compnerd and @jyknight).

Apr 9 2019, 7:53 AM · Restricted Project
bd1976llvm updated the diff for D60274: [ELF] Implement Dependent Libraries Feature.

Addressed review comments.

Apr 9 2019, 7:24 AM · Restricted Project

Apr 8 2019

bd1976llvm added a comment to D60242: Add IR support, ELF section and user documentation for partitioning feature..
In D60242#1456509, @pcc wrote:

Hi Peter,

I really like the concept. I had some nebulous concerns when I read the RFC; but, I didn't comment as I couldn't think of any alternatives to what you were proposing. What I am writing here is still not fully formed.. so feel free to ignore if it is unhelpful.

My main concern is that this is supporting a rare usecase and I don't really like the idea of adding complexity to the core tools for niche cases.

I feel like it would be better if this could be implemented via post-processing in some way; outside of the core tools.

Some aspect of this, like the linker being able to report all of the functions reachable from a given set of entry points, are of general utility though.

I wonder if there is any scope for implementing something different along the lines of:

  1. Do an initial link.
  2. Analyse the resulting elf and report all of the functions in each partition.
  3. Do another link but this time provide an ordering file so that all of the functions for each partition are placed contiguously.
  4. Extract the functions for each partition, apart form the first, into a partition file which also contains metadata specifying the address range.
  5. Write zeros over all of the functions apart from those in the main partition and then compress the executable (saving the file space).
  6. A loader extension patches in the missing functions for each partition when needed.

Hi Ben, thanks for the feedback. I shared a similar concern around complexity, but I don't see any reasonable alternatives to implementing this directly in the linker.

Your idea of using orderfiles is interesting, but I see at least two showstopper problems with it. The first is that it is incompatible with range extension thunks. Imagine that you have one main partition and two loadable partitions. An orderfile is used to sort the main partition's sections before partition 1's sections before partition 2's sections. We're going to split partition 1 and partition 2 into separate files, but the linker doesn't know that, so it may place a range extension thunk in the middle of partition 1's sections and have partition 2 call it. Now at runtime we will crash if partition 2 is loaded without partition 1 and it tries to call one of the range extension thunks in partition 1. We might be able to work around this issue somehow by telling the linker where the partition boundaries are, but at that point since the linker needs to know how you're going to split the file up anyway it might as well actually split it up for you.

The second is that replacing parts of the file with zeros and compressing it isn't always useful from a size perspective; in many cases it's the uncompressed size that matters because that's what takes up storage space on the device. One might consider uncompressing the code at program startup but that leads to other problems: it slows down startup and prevents the kernel from paging out the pages containing the uncompressed code.

I also see other problems that aren't showstoppers but are still significant:

  • We're leaving some of the binary size gains on the table because we can't move exception-handling sections, dynamically relocatable sections (e.g. vtables) or symbol tables.
  • Since we aren't splitting the symbol table the solution is more error prone since there's nothing stopping someone from dlsym'ing a symbol in an unloaded partition.
  • This requires linking multiple times, which will slow down linking and hurt developer productivity, but the problem is made worse when (full) LTO is being used since we'll need to do LTO multiple times.
Apr 8 2019, 7:49 AM · Restricted Project
bd1976llvm added inline comments to D60274: [ELF] Implement Dependent Libraries Feature.
Apr 8 2019, 7:01 AM · Restricted Project

Apr 5 2019

bd1976llvm added inline comments to D60274: [ELF] Implement Dependent Libraries Feature.
Apr 5 2019, 2:31 PM · Restricted Project
bd1976llvm added a comment to D60274: [ELF] Implement Dependent Libraries Feature.

The early check for ELF is the problem. I care very little about .linker-options itself as long as the ability to ensure that framework linkage is provided (i.e. -framework ..., and '-L ...` can be passed along as options to the linker).

Apr 5 2019, 10:42 AM · Restricted Project
bd1976llvm added a comment to D60274: [ELF] Implement Dependent Libraries Feature.

Am I mistaken in that this effectively prevents the use of options to handle frameworks? That really is a strong requirement and should be part of this patch.

Apr 5 2019, 9:48 AM · Restricted Project
bd1976llvm added a comment to D60242: Add IR support, ELF section and user documentation for partitioning feature..

Hi Peter,

Apr 5 2019, 2:45 AM · Restricted Project

Apr 4 2019

bd1976llvm created D60274: [ELF] Implement Dependent Libraries Feature.
Apr 4 2019, 10:19 AM · Restricted Project

Mar 28 2019

bd1976llvm added a comment to D59553: [LLD][ELF][DebugInfo] llvm-symbolizer shows incorrect source line info if --gc-sections used.

Apologies that I didn't check the information on the original bug. The GDB behaviour does look reasonable, thanks.

Mar 28 2019, 10:07 AM · lld, Restricted Project

Mar 22 2019

bd1976llvm added a comment to D59553: [LLD][ELF][DebugInfo] llvm-symbolizer shows incorrect source line info if --gc-sections used.

<Trying again via phabricator rather than replying on the list.>

Mar 22 2019, 3:57 AM · lld, Restricted Project

Mar 21 2019

bd1976llvm added a comment to D59553: [LLD][ELF][DebugInfo] llvm-symbolizer shows incorrect source line info if --gc-sections used.

Does this do the right thing for a 32-bit target? 64-bit is common, but not universal.

Re. the underlying DWARF issues:
I can't remember whether the DWARF committee has ever considered specifying a special value for "address does not exist" but I doubt it, because the DWARF spec states "If an entity has no associated machine code, none of these [address-related] attributes are specified." (DWARF v5 section 2.17, p.51.) So, the current position of the DWARF spec is that the linker is supposed to rewrite the DWARF, I guess.

I don't think that's the intent of the DWARF standard/committee - it's been pretty careful about designing features that work with existing linker behavior without requiring the linker to be DWARF aware in any way.

Likely the best way to solve this would be to put the debug information for the rest of it in the same section group as the function. In particular the subprogram die for the concrete function should be in a section group along with the function. This was part of the considerations with bringing other things back into the debug_info section in dwarf5 as well.

I'd worry about the overhead of making hunks of standalone DIEs for every function. (though, that said - we do actually use 4 bytes for both a CU-relative offset, and for a sec_offset, I think - so maybe it doesn't matter /that/ much (adding a unit header would be the main cost - and maybe that's significant enough to be problematic size-wise too)).

Currently linkers don't eliminate debug info for garbage-collected sections, so the debug info for exectuables/shared objects are larger than necessary, so you could save bytes of the final output by using more bytes for intermediate object files. That doesn't seem like a bad deal to me.

Mar 21 2019, 3:26 AM · lld, Restricted Project

Jan 16 2019

bd1976llvm added a comment to D56437: Support blank flag in SHT_GROUP sections for ELF.

I strongly feel that we shouldn't implement this. This will tie groups and --gc-sections together when they are orthogonal features; e.g. COMDAT groups will *also* have to be considered by --gc-sections as a single unit. The ability to strip individual sections form COMDAT groups is an important feature. I will add similar comment to the abi list. I'm surprised that gold implements this behavior, back in 2017 gold and bfd-ld disagreed on this.

Jan 16 2019, 12:45 AM

Jan 10 2019

bd1976llvm added a comment to D56516: [SanitizerCoverage] Don't create comdat for interposable functions..

@bd1976llvm: So do you still think this is a compiler bug? It sounds like ELF provides no guarantees about which COMDAT is kept. Which would mean we need to keep the weak symbols from going in a COMDAT.

Jan 10 2019, 1:32 PM
bd1976llvm added a comment to D56516: [SanitizerCoverage] Don't create comdat for interposable functions..

Does weak-vs-strong count towards that "api"? Because that's the only difference in the case I'm seeing...

Jan 10 2019, 12:34 PM
bd1976llvm added a comment to D56437: Support blank flag in SHT_GROUP sections for ELF.

@bd1976llvm interesting. Unfortunately I failed to find this thread :-/

Jan 10 2019, 4:01 AM
bd1976llvm added a comment to D56516: [SanitizerCoverage] Don't create comdat for interposable functions..
In D56516#1351953, @pcc wrote:

Can you create a minimal reproducer?

If objcopy is complaining about sh_link = 0 I suspect that there's some issue where a global referenced via !associated is being dropped.

Jan 10 2019, 3:54 AM

Jan 9 2019

bd1976llvm added a comment to D56437: Support blank flag in SHT_GROUP sections for ELF.

The wording of the standard is unfortunate. This has been brought up and clarified (that COMDATs are the only legal groups currently) on the list previously.

Jan 9 2019, 7:43 AM
bd1976llvm added a comment to D53234: Don't remove COMDATs when internalizing global objects.

There is a relevant discussion about non-COMDAT groups here: https://reviews.llvm.org/D56437.

Jan 9 2019, 7:27 AM
bd1976llvm added a comment to D56437: Support blank flag in SHT_GROUP sections for ELF.

I agree with Rui. My understanding is that groups in ELF were designed specifically to support C++ templates and inline functions which is why COMDAT groups are the only allowed kind.
Interestingly, I have been having a somewhat related discussion on this review: https://reviews.llvm.org/D53234.
Could the annobin tool use SHF_LINK_ORDER instead?

Jan 9 2019, 7:26 AM

Dec 21 2018

bd1976llvm added a comment to D53234: Don't remove COMDATs when internalizing global objects.

We need to resolve this point of disagreement. IMO that optimization is only invalid in regular compilation. I think that for LTO this is a valid optimization. LTO has optimizations that would normally be invalid - for example the Internalize pass.

I think the issue here is that an LLVM COMDAT has two different purposes:

  1. De-duplicate section groups
  2. Ensure that section group members are kept/removed as a unit

    In ELF files, you can have non-COMDAT section groups, which only accomplish purpose 2.
Dec 21 2018, 2:13 AM

Nov 28 2018

bd1976llvm added a comment to D53234: Don't remove COMDATs when internalizing global objects.
  1. Retain the comdats in the output (this patch). Limits the optimization potential of LTO. !associated metadata sections don't need to be in a comdats.

I don't believe that this is the right way to think about this. This patch prevents LLVM from performing an invalid optimization - that is, selectively discarding global objects that the IR explicitly indicates should stay together.

Nov 28 2018, 5:12 AM

Nov 26 2018

bd1976llvm added a comment to D53234: Don't remove COMDATs when internalizing global objects.

Trying again... Phabricator didn't like the markup in my last comment attempt.

Nov 26 2018, 6:08 PM
bd1976llvm added a comment to D53234: Don't remove COMDATs when internalizing global objects.
Nov 26 2018, 6:04 PM

Nov 16 2018

bd1976llvm added a comment to D53234: Don't remove COMDATs when internalizing global objects.

Hi Araon,

Nov 16 2018, 2:36 AM

Oct 31 2018

bd1976llvm added a comment to D53242: [Inliner] Only remove functions with a COMDAT when it's safe to do so.

Hi Aron, I'm interested in reviewing this. Would you mind responding to my comments on https://reviews.llvm.org/D53234 first, as you have based the correctness of this on the correctness of that change?

Oct 31 2018, 10:37 AM
bd1976llvm added a comment to D53234: Don't remove COMDATs when internalizing global objects.

So perhaps this code needs to handle comdat containing an object with associated metadata specially (e.g. could just include in the ExternalComdats set)?

My concern is that the current behavior would still be incorrect for other uses of COMDATS - or at the very least, quite counterintuitive.
If I specify a COMDAT for two global objects, I would expect one of the following things to happen:

  1. Both objects appear in the final object, both still in the COMDAT.
  2. Neither object appears in the final object, and the COMDAT section does not exist (both objects were optimized out).

    Having only one of the two objects be present, and having it lack a COMDAT, seems very unexpected to me - especially considering that the COMDAT section can be read using external tools (e.g. readelf).
Oct 31 2018, 10:35 AM

Sep 5 2018

bd1976llvm added a comment to D51536: [LLD] Do not set alignment to entsize for mergable sections if entsize is not a power of 2.

Thanks for the comments everyone.

Sep 5 2018, 7:53 AM

Aug 31 2018

bd1976llvm updated the diff for D51536: [LLD] Do not set alignment to entsize for mergable sections if entsize is not a power of 2.

Added missing newline at end of test file

Aug 31 2018, 5:30 AM
bd1976llvm created D51536: [LLD] Do not set alignment to entsize for mergable sections if entsize is not a power of 2.
Aug 31 2018, 5:27 AM
bd1976llvm committed rL341207: [LLD] Add test missed from r341206. NFC..
[LLD] Add test missed from r341206. NFC.
Aug 31 2018, 5:10 AM
bd1976llvm committed rLLD341207: [LLD] Add test missed from r341206. NFC..
[LLD] Add test missed from r341206. NFC.
Aug 31 2018, 5:10 AM
bd1976llvm committed rLLD341206: [LLD] Check too large offsets into merge sections earlier.
[LLD] Check too large offsets into merge sections earlier
Aug 31 2018, 4:55 AM
bd1976llvm committed rL341206: [LLD] Check too large offsets into merge sections earlier.
[LLD] Check too large offsets into merge sections earlier
Aug 31 2018, 4:55 AM
bd1976llvm closed D51180: [LLD] Check for too large offsets into merge sections earlier to avoid DenseMap tombstone collision.
Aug 31 2018, 4:55 AM

Aug 23 2018

bd1976llvm retitled D51180: [LLD] Check for too large offsets into merge sections earlier to avoid DenseMap tombstone collision from [LLD] Check for too large offsets into merge sections earlier to avoid DenseMap tombstone collsiion to [LLD] Check for too large offsets into merge sections earlier to avoid DenseMap tombstone collision.
Aug 23 2018, 1:28 PM
bd1976llvm created D51180: [LLD] Check for too large offsets into merge sections earlier to avoid DenseMap tombstone collision.
Aug 23 2018, 1:21 PM

Aug 22 2018

bd1976llvm added a comment to D51027: [LLD][ELD] - Do not reject INFO output section type when used with a start address..

Thanks for the detailed reply Peter!

Aug 22 2018, 1:58 AM

Aug 21 2018

bd1976llvm added a comment to D50688: [LLD] Warn if non-alloc sections occur before alloc sections in linker scripts.

Thanks for the link! However, I'm not sure if this is really related. The issue there was that a non-alloc section should be placed into a program header explicitly via PHDRS commands, which might be a valid use case.

Aug 21 2018, 7:41 AM
bd1976llvm added a comment to D51027: [LLD][ELD] - Do not reject INFO output section type when used with a start address..

Also, note that we already support the following:

.stack address_expression (NOLOAD) :
{

but not the

.stack address_expression (INFO) :
{

yet. So I think it is worth to implement both for consistency and few users we have.

Aug 21 2018, 4:20 AM
bd1976llvm added a comment to D51027: [LLD][ELD] - Do not reject INFO output section type when used with a start address..

Hi George. Do we actually want this behaviour?

Aug 21 2018, 3:43 AM

Aug 20 2018

bd1976llvm added a comment to D50688: [LLD] Warn if non-alloc sections occur before alloc sections in linker scripts.

Hi. Sorry to be slow to comment on this.

Aug 20 2018, 5:55 PM

Aug 2 2018

bd1976llvm updated subscribers of D48577: [llvm-ar] Correct help text.

This wasn't committed in time for the 7.0 release but I wonder if rL338703 + rL338709 should be put on the release branch? The current output is slightly embarrassing.

Aug 2 2018, 10:57 AM
bd1976llvm committed rL338709: [llvm-ar] Fix help text test. NFC..
[llvm-ar] Fix help text test. NFC.
Aug 2 2018, 5:27 AM
bd1976llvm committed rL338703: [llvm-ar] Correct help text.
[llvm-ar] Correct help text
Aug 2 2018, 4:28 AM
bd1976llvm closed D48577: [llvm-ar] Correct help text.
Aug 2 2018, 4:28 AM

Jul 23 2018

bd1976llvm added a comment to D49622: ELF: Make sections with KeepUnique bit eligible for ICF..

Hi Peter,

Jul 23 2018, 5:17 AM
bd1976llvm added a comment to D48577: [llvm-ar] Correct help text.

ping!

Jul 23 2018, 4:32 AM

Jun 28 2018

bd1976llvm added inline comments to D48577: [llvm-ar] Correct help text.
Jun 28 2018, 5:21 AM
bd1976llvm updated the diff for D48577: [llvm-ar] Correct help text.

updated diff to address review comments

Jun 28 2018, 5:12 AM
bd1976llvm added a reviewer for D48577: [llvm-ar] Correct help text: Bigcheese.
Jun 28 2018, 4:29 AM

Jun 26 2018

bd1976llvm updated the diff for D48577: [llvm-ar] Correct help text.

Having thought about this I have decided to try to simplify the help text as much as possible to aid maintenance.

Jun 26 2018, 7:30 AM

Jun 25 2018

bd1976llvm created D48577: [llvm-ar] Correct help text.
Jun 25 2018, 6:27 PM

Jun 22 2018

bd1976llvm added a comment to D48298: [ELF] Uniquify --wrap list..

I would propose adding the ability to retrieve a unique filtered list of arguments.

for (StringRef Name : Args.getAllUniqueArgValues(OPT_wrap))
  Symtab->addSymbolWrap<ELFT>(Name);

Relevant for other options: --defsym, --trace-symbol, --undefined etc..

I am not sure it is useful for other options we have, but it perhaps can be a nice refactoring for this particular case.

For example, I am not sure we should use it for --defsym, as in theory it can have different values: --defsym=foo=1 ... --defsym=foo=2.
It is OK to process all of them one by one like we do now. The same applies for --trace-symbol and --undefined - there is no issue to process them one by one.
I would not overcomplicate the current code for these cases until it is proven to be a useful change.

Jun 22 2018, 2:22 AM

Jun 19 2018

bd1976llvm added a comment to D48298: [ELF] Uniquify --wrap list..

I would propose adding the ability to retrieve a unique filtered list of arguments.

Jun 19 2018, 2:25 AM

Jun 4 2018

bd1976llvm added a comment to D47588: Print out "Alias for -foo" instead of repeating the same help message for -foo..

Hi Rui,

Jun 4 2018, 7:25 AM

May 31 2018

bd1976llvm added a comment to D47540: [lld] Enable Visual Studio compatible output.

Hi Rui! Thanks for looking at the patch.

May 31 2018, 4:02 AM

Mar 27 2018

bd1976llvm added a comment to D44669: Use local symbols for creating .stack-size.

Why are extra symbols *in the assembly* a problem? We normally don't print assembly

Mar 27 2018, 11:55 AM
bd1976llvm added a comment to D44669: Use local symbols for creating .stack-size.

Hi Rafael,

Mar 27 2018, 9:16 AM
bd1976llvm added a comment to D44669: Use local symbols for creating .stack-size.

Hi Rafael. The SN-Linker has the following rule for metadata sections:

Mar 27 2018, 3:36 AM

Mar 26 2018

bd1976llvm added a comment to D44669: Use local symbols for creating .stack-size.

LGTM., as long as this doesn't cause the number of symbols to double up?

Mar 26 2018, 8:59 AM

Jan 19 2018

bd1976llvm added inline comments to D42267: [ThinLTO] Allow 0 to be a valid value for pruning interval for C LTO API..
Jan 19 2018, 5:03 AM

Dec 22 2017

bd1976llvm committed rL321376: [ThinLTO][CachePruning] explicitly disable pruning.
[ThinLTO][CachePruning] explicitly disable pruning
Dec 22 2017, 10:33 AM
bd1976llvm closed D41497: [ThinLTO][CachePruning] explicitly disable pruning.
Dec 22 2017, 10:33 AM
bd1976llvm added inline comments to D41497: [ThinLTO][CachePruning] explicitly disable pruning.
Dec 22 2017, 10:25 AM
bd1976llvm added inline comments to D41497: [ThinLTO][CachePruning] explicitly disable pruning.
Dec 22 2017, 9:58 AM