Page MenuHomePhabricator
Feed Advanced Search

Fri, Nov 20

smeenai added inline comments to D91891: [lld-macho] Don't warn on non-existent system libraries.
Fri, Nov 20, 5:25 PM

Tue, Nov 17

smeenai added inline comments to D91574: [libc++] Simplify how we pick the typeinfo comparison.
Tue, Nov 17, 1:28 PM · Restricted Project
smeenai added a comment to D91574: [libc++] Simplify how we pick the typeinfo comparison.

Thanks!

Tue, Nov 17, 10:09 AM · Restricted Project
smeenai added a comment to D91574: [libc++] Simplify how we pick the typeinfo comparison.

We have a large internal codebase that I migrated from libstdc++ to libc++. libstdc++ uses relaxed typeinfo comparisons, and I found that just naively switching to libc++ produced hundreds of exception-related issues. Configuring libc++ to use the non-unique implementation was by far the easiest way to get this codebase working. I'm aware that in most cases, there is a proper fix for the exception issues, but (a) it's really hard to justify the large time investment required to fix all the different issues, and (b) there's some cases involving dlopen and RTLD_LOCAL that I believe are impossible to get right with the unique implementation (and I think that was the motivation for libstdc++ to switch to relaxed typeinfo comparisons).

Getting rid of the configurability seems problematic at least for ELF, where there's good reasons to want to use either the unique or non-unique implementations.

Interesting, thanks for the information. This is the sort of feedback I was looking for when putting up this review.

In that case, what I'll do instead is clarify that LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION allows unconditionally overriding the implementation of typeinfo used, and have the non unique ARM implementation be _LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION == 3 like in this patch. It'll get rid of most of the confusing-ness while still letting you override it.

Tue, Nov 17, 9:39 AM · Restricted Project

Mon, Nov 16

smeenai added a comment to D91574: [libc++] Simplify how we pick the typeinfo comparison.

We have a large internal codebase that I migrated from libstdc++ to libc++. libstdc++ uses relaxed typeinfo comparisons, and I found that just naively switching to libc++ produced hundreds of exception-related issues. Configuring libc++ to use the non-unique implementation was by far the easiest way to get this codebase working. I'm aware that in most cases, there is a proper fix for the exception issues, but (a) it's really hard to justify the large time investment required to fix all the different issues, and (b) there's some cases involving dlopen and RTLD_LOCAL that I believe are impossible to get right with the unique implementation (and I think that was the motivation for libstdc++ to switch to relaxed typeinfo comparisons).

Mon, Nov 16, 4:59 PM · Restricted Project

Wed, Nov 11

smeenai requested changes to D90025: add LLVM_INCLUDE_LIB CMake option .

Yeah, in general, we've tried to move away from configure-time options for parts of the build like this (CC @beanz and @tstellar). The separate build root for the runtimes is the way to go here.

Wed, Nov 11, 12:58 PM · Restricted Project
smeenai added inline comments to D76570: [AArch64] Homogeneous Prolog and Epilog for Size Optimization.
Wed, Nov 11, 11:49 AM · Restricted Project

Tue, Nov 10

smeenai added a comment to D80376: [libc++] [P1208] [C++20] Adopt source location from Library Fundamentals V3 for C++20..

I've updated the "unsupported" comments with precise compiler versions. I cannot test apple-clang though.
Anyway, I'll put this revision into hibernation until there's a builtin for a single-pointer source location (whether it be __bultin_source_location or T* __builtin_static_storage_duration(T)).

Tue, Nov 10, 10:52 AM · Restricted Project

Mon, Nov 9

smeenai accepted D90663: [lld-macho] Add very basic support for LTO.

LGTM, very nice :)

Mon, Nov 9, 6:53 PM · Restricted Project
smeenai accepted D89418: [lld-macho] Implement LC_UUID.

LGTM

Mon, Nov 9, 6:50 PM · Restricted Project
smeenai added a comment to D89257: [lld-macho] Emit STABS symbols for debugging, and drop debug sections.

We could just add a size field to our Symbol class. This seems simpler, and I'm more inclined toward it, but I'm not sure if there are use cases that it doesn't handle well. As such I'm punting on the decision for now.

Mon, Nov 9, 6:41 PM · Restricted Project
smeenai accepted D89285: [lld-macho] Emit local symbols in symtab; record metadata in LC_DYSYMTAB.

LGTM

Mon, Nov 9, 6:24 PM · Restricted Project
smeenai accepted D89012: [lld-macho] Support linking against stub dylibs.

LGTM

Mon, Nov 9, 6:15 PM · Restricted Project
smeenai added a comment to D45639: [Driver] Support default libc++ library location on Darwin.
  • AppleClang prefers the headers in the SDK, and the library in the SDK. (The headers are currently still shipped in the toolchain but they should be ignored if you have a sufficiently recent SDK that contains the headers -- this is transitional only).

How recent is this change? I have Xcode 12, and I still see the C++ headers as only being included in the toolchain (Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1) and not any of the SDKs.

Mon, Nov 9, 12:46 PM

Fri, Nov 6

smeenai added inline comments to D89177: [cmake] Add support for multiple distributions.
Fri, Nov 6, 3:48 PM · Restricted Project, Restricted Project, Restricted Project
smeenai accepted D90690: [llvm-objcopy][MachO] Fix adding multiple sections.

LGTM

Fri, Nov 6, 12:17 PM · Restricted Project

Tue, Nov 3

smeenai added a comment to D90690: [llvm-objcopy][MachO] Fix adding multiple sections.
In D90690#2372192, @eqv wrote:

Any ideas why seemingly unrelated tests are failing? Is this something I should worry about?

Tue, Nov 3, 1:36 PM · Restricted Project
smeenai added a comment to D90690: [llvm-objcopy][MachO] Fix adding multiple sections.

Mechanical note: we try to keep the first line of the commit message concise (preferably under 72 characters; some people try to keep it under 50). We also usually add tags in square brackets to indicate the areas the patch touches. A conventional subject line for this commit would be something like:

Tue, Nov 3, 1:12 PM · Restricted Project
smeenai added a comment to D89177: [cmake] Add support for multiple distributions.

Ping.

Tue, Nov 3, 9:43 AM · Restricted Project, Restricted Project, Restricted Project

Mon, Nov 2

smeenai added a comment to D90476: [libcxxabi] Build all of libcxxabi with _LIBCPP_BUILDING_LIBRARY defined.

This is definitely a good cleanup IMO. I wonder if this should be taken a step further and use the "standard" (well, as far as CMake is concerned) standard macros of LIBCXX_EXPORTS. Of course, that is probably done better in a subsequent change.

Mon, Nov 2, 10:01 AM · Restricted Project
smeenai committed rG6bd01b8184de: [clangd] Account for vendor in version string (authored by smeenai).
[clangd] Account for vendor in version string
Mon, Nov 2, 9:05 AM
smeenai committed rG4e4ab8e0152b: [clang] Limit scope of CLANG_VENDOR definition (authored by smeenai).
[clang] Limit scope of CLANG_VENDOR definition
Mon, Nov 2, 9:05 AM
smeenai closed D90517: [clangd] Account for vendor in version string.
Mon, Nov 2, 9:05 AM · Restricted Project
smeenai closed D90516: [clang] Limit scope of CLANG_VENDOR definition.
Mon, Nov 2, 9:05 AM · Restricted Project
smeenai abandoned D90518: [clangd] Make tests depend on Clang.

Cool, thanks for fixing it better!

Mon, Nov 2, 9:03 AM · Restricted Project
smeenai added a comment to D90528: [clangd] Fix check-clangd with no clang built.

Thanks!

Mon, Nov 2, 9:03 AM · Restricted Project, Restricted Project

Fri, Oct 30

smeenai requested review of D90518: [clangd] Make tests depend on Clang.
Fri, Oct 30, 5:47 PM · Restricted Project
smeenai requested review of D90517: [clangd] Account for vendor in version string.
Fri, Oct 30, 5:47 PM · Restricted Project
smeenai requested review of D90516: [clang] Limit scope of CLANG_VENDOR definition.
Fri, Oct 30, 5:47 PM · Restricted Project

Wed, Oct 28

smeenai added a comment to D45639: [Driver] Support default libc++ library location on Darwin.
  • AppleClang prefers the headers in the SDK, and the library in the SDK. (The headers are currently still shipped in the toolchain but they should be ignored if you have a sufficiently recent SDK that contains the headers -- this is transitional only).
Wed, Oct 28, 3:38 PM
smeenai abandoned D31363: [libc++] Remove cmake glob for source files.
Wed, Oct 28, 1:11 PM

Oct 26 2020

smeenai updated subscribers of D89418: [lld-macho] Implement LC_UUID.

Hi,

Sorry to post this around a week late. I've been noticing that the same lit test that failed here (windows > lld.ELF/invalid::symtab-sh-info.s) is failing in my local build. I tried to debug it and noticed that a dense map is being deallocated, but it is a nullpointer. Is this a known issue? I apologies if I'm asking in the wrong place. Thanks for your time.

Oct 26 2020, 6:01 PM · Restricted Project

Oct 23 2020

smeenai accepted D88722: [llvm-libtool-darwin] Add support for LLVM bitcode files.

LGTM, sorry for the slow review.

Oct 23 2020, 9:07 PM · Restricted Project

Oct 22 2020

smeenai updated subscribers of D89915: [compiler-rt] Don't include libc++ headers from the source tree in MSAN.

Subscribing @phosek because he's been looking into some sanitizer build issues with the C++ headers recently as well (D88922).

Oct 22 2020, 7:27 PM · Restricted Project

Oct 20 2020

smeenai added a comment to D89561: [MC] Adjust StringTableBuilder for linked Mach-O binaries.

@mtrent, do you have the historical context for why ld64 adds a leading space to the string table?

Yes.

The actual details are locked in an office in a building I don't have access to because of global pandemic. But I can give you the gist with citations. I'm also not the right person to ask, but I'm the person most likely to answer this question, so, hey, maybe I am!

However, the Mach-O documentation says:

A union that holds an index into the string table, n_strx. To specify an empty string (""), set this value to 0.

The Mach-O file format descends in part from the UNIX a.out file format. Both (the new defunct) ld and ld64 agree on the historical definition of n_strx as defined in the historical a.out(5) manpage. I believe the original BSD 4.2, 4.3, 4.4 man pages had this definition, and here is where I have to get a little hand-wavy. But this link from the Internet has text that matches my memory of that historical man content (and note that this differs from newer versions of the a.out man page):

http://man.cat-v.org/unix_8th/5/a.out

In the a.out file a symbol's n_un.n_strx field gives an
index into the string table.  A n_strx value of 0 indicates
that no name is associated with a particular symbol table
entry.  The field n_un.n_name can be used to refer to the
symbol name only if the program sets this up using n_strx
and appropriate data from the string table.

Let me call your attention to this sentence:

A n_strx value of 0 indicates that no name is associated with a particular symbol table entry.

A strict reading of this sentence is: If you encounter a n_strx value of 0, there is no string for this value, therefore do not consult the strings table.

Kevin's ld linker agreed with this position, a n_strx == 0 means don't look at the string table, but as a matter of mercy also wrote a \0 byte at the front of the string table, in case someone accidentally dereferenced the string table anyway. If they accidentally tried to read a string from index 0 they'd get back a null terminated string, instead of crashing or getting whatever string happened to be the first item in the string table.

Nick's ld64 linker agreed with this position, a n_strx == 0 means don't look at the string table, but thought "if you get a null string back, that might not be a strong enough indication that you are reading an illegal value from the string table." Consider the case where nm prints an address and then prints the name of the symbol at that address. If you get back "" no name will be printed so there's no indication something went wrong. But if you got back something that wasn't "" you have a chance of noticing something bad has happened. So instead of writing a \0 byte at the front of the string table, ld64 writes a " \0" string at the front of the string table. Then everyone who writes code that walks the nlist can have a unit test that tests for strings that say " " and then fail their test: you're not allowed to look at the string table if n_strx is 0, so if your symbol name is " " you have a bug in your program. Of course, no one actually writes this test, and every Mach-O binary has an extra byte in it. But that's what it's there for. Why Nick chose ' ' and not a visible character that isn't a valid symbol name like '*' or '~' I have no idea.

The thing both ld and l64 have in common is both agree the value of a string at index 0 in the string table is undefined. And that's the most important takeaway. ld64 chooses to write a non-trivial string at this location to help you find your bugs. ld chooses to write an empty string at this location out of a sense of mercy. Neither are wrong. You could write a linker that stores "YOU HAVE A BUG IN YOUR PROGRAM" at the start of the strings table and your linker would not be wrong.

which suggests that the first byte of the string table should be the 0 byte and not the space.

I'm not familiar with the documentation you are citing. It sounds like it's describing the implications of the original ld behavior, but not it's reasoning.

mach-o/nlist.h is a bit more ambiguous. It says:

/*
 * Symbols with a index into the string table of zero (n_un.n_strx == 0) are
 * defined to have a null, "", name.  Therefore all string indexes to non null
 * names must not have a zero string index.  This is bit historical information
 * that has never been well documented.
 */

This comment documents the original ld behavior. It has been known to happen that ld64 has changed the format of the Mach-O binary without updating the appropriate header files or man pages. This might be one of those situations.

Oct 20 2020, 10:01 PM · Restricted Project
smeenai accepted D89639: [lld-macho] Emit empty string as first entry of string table.

LGTM

Oct 20 2020, 10:00 PM · Restricted Project

Oct 19 2020

smeenai updated subscribers of D89561: [MC] Adjust StringTableBuilder for linked Mach-O binaries.
Oct 19 2020, 7:31 PM · Restricted Project
smeenai added a comment to D89561: [MC] Adjust StringTableBuilder for linked Mach-O binaries.

@mtrent, do you have the historical context for why ld64 adds a leading space to the string table? The relevant lines from its code are:

Oct 19 2020, 7:30 PM · Restricted Project
smeenai added a comment to D89639: [lld-macho] Emit empty string as first entry of string table.

Do we have any logic to emit an n_strx for an empty string? If so, that would need to be adjusted to emit 1 instead of 0. If not, LGTM.

Oct 19 2020, 7:03 PM · Restricted Project
smeenai added a comment to D89177: [cmake] Add support for multiple distributions.

Ping. Assuming everyone is okay with the direction, any comments on the change itself?

Oct 19 2020, 2:24 PM · Restricted Project, Restricted Project, Restricted Project
smeenai accepted D89661: [llvm-objcopy][MachO] Fix the calculation of the output size.

LGTM

Oct 19 2020, 12:03 PM · Restricted Project

Oct 16 2020

smeenai accepted D89555: [CMake] Don't add -lstdc++ to LDFLAGS.

Both CMake and the driver (assuming it's invoked as clang++/g++) should take care of adding the C++ standard library, so this LGTM.

Oct 16 2020, 11:43 AM

Oct 15 2020

smeenai added a comment to D89177: [cmake] Add support for multiple distributions.

That isn't what I meant. It's entirely okay for the runtimes to be driven via AddExternalProject like the runtimes build does, since that's akin to having a separate CMake invocation for each configuration. That's okay.

What I'm saying is that if the next logical step is to also add support for multiple distributions in libc++'s build itself (e.g. adding LIBCXX_<DISTRIBUTION>_ENABLE_SHARED & al), then I don't think that's a good idea.

Totally agree. That would be the path compiler-rt’s Darwin build goes, and it is a frequent problem.

Oct 15 2020, 5:10 PM · Restricted Project, Restricted Project, Restricted Project

Oct 14 2020

smeenai added inline comments to D88922: [CMake] Avoid accidental C++ standard library dependency in sanitizers.
Oct 14 2020, 11:55 PM · Restricted Project
smeenai accepted D88922: [CMake] Avoid accidental C++ standard library dependency in sanitizers.

This is needed to avoid potential race conditions where some of the C++ headers have been copied but not all of them, and some other runtime that doesn't depend on the C++ headers sees this incomplete state and gets a spurious build failure, so LGTM.

Oct 14 2020, 6:15 PM · Restricted Project
smeenai updated subscribers of D89177: [cmake] Add support for multiple distributions.

We've already considered introducing a similar mechanism so thank you for working on this! There's one issue that I haven't figured out how to resolve and I'd be interested in your thoughts: building executables and libraries in the most optimal may require incompatible flags. For example, when building a shared library you have to use -fPIC but for executables that's suboptimal; similarly, when building executables you may want to use LTO but if you also want to create a distribution that contains static libraries, that's a problem because those will contain bitcode. So far our solution has been to simply do multiple builds with different flags (in GN this can be done in a single build by leveraging the "toolchain" concept that also allows sharing as much work as possible, but I haven't figured out how to do anything like that in CMake).

Good question. We need something similar as well, where some clients of the libraries want them built with RTTI (because their programs rely on RTTI and you can get link errors when linking them against non-RTTI LLVM libraries), but we don't wanna build the executables with RTTI because of the size increases.

We recently ran into this as well where we need RTTI for LLVM libraries but don't want to enable it for the toolchain.

I don't know of any way to do this in CMake other than just configuring multiple times with the different flags, like you said. Maybe we could implement some logic for that in the build system, but I'm not sure if it's worth it. (I'm wondering if the Ninja multi-config generator added in CMake 3.17 could be useful for this, although I haven't played around with that at all yet.) I do recognize it limits the usefulness of this approach quite a bit (since if you're doing separate configurations you can just do different LLVM_DISTRIBUTION_COMPONENT settings), but I'm hoping it can still be valuable for simpler scenarios.

One idea I had would be to eliminate the use of global variables like CMAKE_C_FLAGS and CMAKE_CXX_FLAGS and always set these via target_compile_options (which is something we should do in any case to move towards more modern CMake); since we always use functions like add_llvm_component_library to create targets in LLVM, we could then have these create multiple targets that would differ in flags like -fPIC or -frtti and set up dependencies among these appropriately. It means you'd have to build files multiple times (I don't think there's any way around that) but you'd save time on things like tablegen.

Oct 14 2020, 3:40 PM · Restricted Project, Restricted Project, Restricted Project
smeenai updated the diff for D89177: [cmake] Add support for multiple distributions.

Address review comments

Oct 14 2020, 3:29 PM · Restricted Project, Restricted Project, Restricted Project

Oct 13 2020

smeenai added a comment to D89177: [cmake] Add support for multiple distributions.

Reading up on the Ninja multi-config generator a bit, you can define your own build types, so you should be able to create e.g. one build type for LTO and another for PIC. You'd still need some external logic to define that you use the LTO mode for executables and the PIC mode for libraries, but the multiple distribution support should work nicely in conjunction with that.

Oct 13 2020, 12:07 AM · Restricted Project, Restricted Project, Restricted Project

Oct 12 2020

smeenai added a comment to D89177: [cmake] Add support for multiple distributions.

We've already considered introducing a similar mechanism so thank you for working on this! There's one issue that I haven't figured out how to resolve and I'd be interested in your thoughts: building executables and libraries in the most optimal may require incompatible flags. For example, when building a shared library you have to use -fPIC but for executables that's suboptimal; similarly, when building executables you may want to use LTO but if you also want to create a distribution that contains static libraries, that's a problem because those will contain bitcode. So far our solution has been to simply do multiple builds with different flags (in GN this can be done in a single build by leveraging the "toolchain" concept that also allows sharing as much work as possible, but I haven't figured out how to do anything like that in CMake).

Oct 12 2020, 11:49 PM · Restricted Project, Restricted Project, Restricted Project
smeenai accepted D88468: [llvm-readobj] Don't print out section names for STABS symbols.

LGTM.

Oct 12 2020, 3:11 PM · Restricted Project

Oct 9 2020

smeenai updated subscribers of D89177: [cmake] Add support for multiple distributions.
Oct 9 2020, 7:38 PM · Restricted Project, Restricted Project, Restricted Project
smeenai requested review of D89177: [cmake] Add support for multiple distributions.
Oct 9 2020, 7:33 PM · Restricted Project, Restricted Project, Restricted Project
smeenai added a comment to D85140: [RFC] Factor out repetitive cmake patterns for llvm-style projects.

Also a styling nit, this should have been cmake/Modules, not cmake/modules. The former is used only by LLVM and is a historic relic, all other projects use cmake/Modules which is more common in CMake-based builds.

Oct 9 2020, 3:35 PM · Restricted Project, Restricted Project
smeenai added a reviewer for D89142: llvmbuildectomy: beanz.
Oct 9 2020, 11:25 AM · Restricted Project

Oct 6 2020

smeenai added a comment to D88922: [CMake] Avoid accidental C++ standard library dependency in sanitizers.

LGTM, but I'll give the sanitizer folks a bit of time to review as well.

Oct 6 2020, 1:50 PM · Restricted Project

Oct 5 2020

smeenai added inline comments to D88176: Explicitly specify CMAKE_AR in WinMsvc.cmake.
Oct 5 2020, 1:20 PM · Restricted Project
smeenai added a comment to D88843: [libcxx] Don't treat Windows specially with visibility annotations.

I think the reason for this restriction is that on Windows, __declspec(dllimport) changes the compiler's code generation to assume that the symbol will be imported (i.e. if the compiler sees a call to a function X which is marked __declspec(dllimport), it'll generate an indirect call to __imp_X instead). If you're linking against libc++ statically, the imported version of the symbol will of course not exist, so you want to disable the __declspec(dllimport) annotations by default if you're building just the static library for Windows.

Oct 5 2020, 11:57 AM · Restricted Project

Oct 2 2020

smeenai added a comment to D88629: [lld-macho] Add ARM64 target arch.

It is not entirely clear whether I use the "ARM64" (Apple) or "AArch64" (non-Apple) naming convention. Guidance is appreciated.

Oct 2 2020, 7:13 PM · Restricted Project
smeenai added a comment to D88400: [llvm-objcopy][MachO] Add support for universal binaries.

LGTM barring the comment about more tests.

Oct 2 2020, 6:43 PM · Restricted Project
smeenai accepted D88372: [Object][MachO] Refactor MachOUniversalWriter.

LGTM

Oct 2 2020, 6:15 PM · Restricted Project
smeenai accepted D88756: [CMake] Don't use CMakePushCheckState.

LGTM

Oct 2 2020, 2:37 PM · Restricted Project

Oct 1 2020

smeenai added a comment to D88454: [CMake] Use -isystem flag to access libc++ headers.

@smeenai do you already have an alternative for your use case?

Oct 1 2020, 11:49 AM · Restricted Project, Restricted Project
smeenai committed rGdcb5b6dfbfb5: [runtimes] Remove TOOLCHAIN_TOOLS specialization (authored by smeenai).
[runtimes] Remove TOOLCHAIN_TOOLS specialization
Oct 1 2020, 9:54 AM
smeenai closed D88627: [runtimes] Remove TOOLCHAIN_TOOLS specialization.
Oct 1 2020, 9:53 AM · Restricted Project
smeenai retitled D88627: [runtimes] Remove TOOLCHAIN_TOOLS specialization from Revert "[AIX] Try to not use LLVM tools while building runtimes" to [runtimes] Remove TOOLCHAIN_TOOLS specialization.
Oct 1 2020, 8:50 AM · Restricted Project
smeenai added a comment to D88627: [runtimes] Remove TOOLCHAIN_TOOLS specialization.

This actually isn't exclusively a revert of D85329 "[AIX] Try to not use LLVM tools while building runtimes" as the title seems to suggest. Before that patch there were already explicit TOOLCHAIN_TOOLS specified in the call to llvm_ExternalProject_Add in the runtimes build, which already suppressed the target-specific tool selection as mention in the description here.

That said, I'm not opposed to the resulting change, which moves all that logic to one place rather than having an extra layer on top just for the runtimes build. We should clarify the title and description though, because removing the TOOLCHAIN_TOOLS here entirely will actually be a new change to how runtimes are built.

Oct 1 2020, 8:49 AM · Restricted Project

Sep 30 2020

smeenai requested review of D88627: [runtimes] Remove TOOLCHAIN_TOOLS specialization.
Sep 30 2020, 6:05 PM · Restricted Project

Sep 28 2020

smeenai added a comment to D88454: [CMake] Use -isystem flag to access libc++ headers.

I was abusing this functionality to be able to get the C++ headers installed without having to build all the runtimes build prerequisites; we have a configuration where we only need the C++ headers installed (and not the library), and using the runtime-libcxx-headers was an easy way to get them without needing to first build Clang and all the other tools the runtimes build requires. I should be able to come up with something else for that use case though.

Sep 28 2020, 5:36 PM · Restricted Project, Restricted Project

Sep 23 2020

smeenai updated subscribers of D87199: [lld-macho] Implement support for PIC.

but would any of this be easier if SyntheticSections were InputSections instead of OutputSections

Maybe... we could make them InputSections and then generate unsigned relocations for each of their entries. There would be some additional overhead (e.g. the addend field would be useless) but it would allow us to handle the rebases in one place. One thing I'm not sure about is whether other architectures have an equivalent of X86_64_RELOC_UNSIGNED that can be used for this; it looks like arm64 does, but not sure about PPC (not that it really matters).

There are other benefits to having SyntheticSections be InputSections: there would no longer be a need for the SectionPointerUnion, and DSOHandle could just be an ordinary Defined symbol.

I actually can't think of many real downsides... do you have any in mind? That said, the current architecture is not terrible, and I'm inclined to work on implementing more features and pushing the refactoring till later.

Sep 23 2020, 11:15 PM · Restricted Project
smeenai added inline comments to D87199: [lld-macho] Implement support for PIC.
Sep 23 2020, 10:58 PM · Restricted Project
smeenai committed rGee7ee71f40e9: Explicitly specify CMAKE_AR in WinMsvc.cmake (authored by Gwen Mittertreiner <gwenm@fb.com>).
Explicitly specify CMAKE_AR in WinMsvc.cmake
Sep 23 2020, 6:06 PM
smeenai closed D88176: Explicitly specify CMAKE_AR in WinMsvc.cmake.
Sep 23 2020, 6:06 PM · Restricted Project
smeenai added a comment to D88176: Explicitly specify CMAKE_AR in WinMsvc.cmake.

The LLVMExternalProjectUtils change is needed either way, but I believe the WinMsvc case to be a CMake bug, and I've put up https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5264 to fix it. (We should still go ahead with it as a workaround for now though.)

Sep 23 2020, 5:12 PM · Restricted Project
smeenai accepted D88176: Explicitly specify CMAKE_AR in WinMsvc.cmake.

https://gitlab.kitware.com/cmake/cmake/-/commit/55196a1440e26917d40e6a7a3eb8d9fb323fa657 is the relevant CMake change, and I believe we need to add logic to find llvm-lib. I'll play with that.

Sep 23 2020, 3:47 PM · Restricted Project
smeenai accepted D88176: Explicitly specify CMAKE_AR in WinMsvc.cmake.

It seems strange for CMake to prefer "ar" to "lib" when targeting Windows. Do you happen to know the CMake change that's responsible?

Sep 23 2020, 11:55 AM · Restricted Project
smeenai accepted D88160: [lld-macho] cleanup unimplemented-option warnings.

You have a small typo in the commit message: s/ldd/lld/

Sep 23 2020, 11:11 AM · Restricted Project

Sep 22 2020

smeenai added inline comments to D87852: [lld-macho] Allow the entry symbol to be dynamically bound.
Sep 22 2020, 2:24 PM · Restricted Project
smeenai accepted D87852: [lld-macho] Allow the entry symbol to be dynamically bound.

LGTM. It's interesting that this is a thing.

Sep 22 2020, 12:52 PM · Restricted Project
smeenai accepted D87909: [lld-macho] Support absolute symbols.

LGTM

Sep 22 2020, 12:21 PM · Restricted Project
smeenai accepted D87856: [lld-macho] Support -bundle.

LGTM

Sep 22 2020, 12:06 PM · Restricted Project
smeenai accepted D87959: [lld-macho][NFC] Refactor syslibroot / library path lookup.

LGTM

Sep 22 2020, 12:00 PM · Restricted Project
smeenai requested changes to D87960: [lld-macho] Always include custom syslibroot when running tests.

The test cleanups are really nice, but I'm not a fan of coding this sort of test-specific behavior (especially the path) into LLD itself :/ (I know we have some precedent with LLD_IN_TEST, but that's only used in canExitEarly and it's a pretty minor behavior change.)

Sep 22 2020, 11:58 AM · Restricted Project

Sep 21 2020

smeenai accepted D88069: [CMake] Use find_dependency in LLVMConfig.cmake.

LGTM

Sep 21 2020, 11:02 PM · Restricted Project
smeenai accepted D88068: [CMake] Use append for CMAKE_REQUIRED_* variables.

LGTM

Sep 21 2020, 11:00 PM · Restricted Project
smeenai added inline comments to D87780: [lld-macho] Export trie addresses should be relative to the image base.
Sep 21 2020, 11:55 AM · Restricted Project

Sep 17 2020

smeenai added inline comments to D87780: [lld-macho] Export trie addresses should be relative to the image base.
Sep 17 2020, 5:00 PM · Restricted Project
smeenai accepted D87780: [lld-macho] Export trie addresses should be relative to the image base.

LGTM

Sep 17 2020, 3:58 PM · Restricted Project

Sep 16 2020

smeenai added a comment to D31413: [libc++] Use __attribute__((init_priority(101))) to ensure streams get initialized early.

What was the conclusion for the comments about the priority level (100 vs. 101)?

Sep 16 2020, 1:09 PM · Restricted Project

Sep 9 2020

smeenai added a comment to D87199: [lld-macho] Implement support for PIC.

Is there a funnel point that we know that all the rebase entries will pass through to ensure that we catch them rather than adding them at a couple of sites?

It may be clearer if we scan the GOT/LazyPointerSection inside RebaseSection::finalizeContents() for any absolute addresses, rather than relying on the code that's adding entries to either of those sections to also handle the rebasing. I will try that... however, there isn't a funnel point that will cover absolute addresses from both our SyntheticSections as well as from InputSections.

Sep 9 2020, 6:16 PM · Restricted Project

Sep 8 2020

smeenai added inline comments to D86805: [lld-macho] create __TEXT,__unwind_info from __LD,__compact_unwind.
Sep 8 2020, 5:17 PM · Restricted Project
smeenai accepted D86908: [lld-macho] Mark weak symbols in symbol table.

LGTM

Sep 8 2020, 1:47 PM · Restricted Project

Aug 28 2020

smeenai added a comment to D86762: [ELF] Add documentation for --warn-backrefs: a GNU ld compatibility checking tool (and lesser of layering detection).

Is there a more specific term than "traditional linker"?

I understand that LLD's search strategy is uncommon among linkers in the Posix (and/or ELF?) realm, but it's not uncommon in other linkers, even very old ones. For example, the VMS (now OpenVMS) linker has used LLD's strategy by default for many decades. (It does allow opting in to the more restrictive search.) LLD's approach matches Microsoft's link.exe. I can't be sure, but I don't recall the so-called traditional behavior from linkers from other vendors of Windows, DOS, or CP/M linkers.

I have no objection to turning the warning on in appropriate contexts or with the argument that it helps to ensure good layering. I'm just quibbling over the term "traditional."

Aug 28 2020, 2:17 PM · Restricted Project

Aug 27 2020

smeenai accepted D86749: [lld-macho][NFC] Define isHidden() in LinkEditSection.

LGTM

Aug 27 2020, 4:47 PM · Restricted Project
smeenai accepted D86746: [lld-macho] Weak locals should be relaxed too.

LGTM; good catch.

Aug 27 2020, 4:11 PM · Restricted Project
smeenai accepted D86575: [lld-macho] Emit binding opcodes for defined symbols that override weak dysyms.

LGTM

Aug 27 2020, 2:24 PM · Restricted Project
smeenai accepted D86728: [lld-macho] Disable invalid/stub-link.s test for Mac.
Aug 27 2020, 11:22 AM · Restricted Project
smeenai accepted D86573: [lld-macho] Implement weak binding for branch relocations.

LGTM

Aug 27 2020, 10:56 AM · Restricted Project

Aug 26 2020

smeenai accepted D86642: [lld-macho] Support GOT relocations to __dso_handle.
Aug 26 2020, 10:01 PM · Restricted Project
smeenai accepted D86641: [lld-macho] Implement GOT_LOAD relaxation.

LGTM

Aug 26 2020, 9:59 PM · Restricted Project
smeenai added inline comments to D86575: [lld-macho] Emit binding opcodes for defined symbols that override weak dysyms.
Aug 26 2020, 9:54 PM · Restricted Project