Page MenuHomePhabricator

krytarowski (Kamil Rytarowski)
User

Projects

User does not belong to any projects.

User Details

User Since
Aug 30 2015, 11:51 AM (181 w, 1 d)

Recent Activity

Today

krytarowski added a comment to D58379: [compiler-rt] Intercept the bcmp() function..

<strings.h> should be included unconditionally.

Tue, Feb 19, 1:44 AM · Restricted Project, Restricted Project
krytarowski added inline comments to D58379: [compiler-rt] Intercept the bcmp() function..
Tue, Feb 19, 1:38 AM · Restricted Project, Restricted Project
krytarowski added a comment to D58379: [compiler-rt] Intercept the bcmp() function..

Please enable the tests for NetBSD as well.

Tue, Feb 19, 1:25 AM · Restricted Project, Restricted Project
krytarowski added a comment to D58379: [compiler-rt] Intercept the bcmp() function..

bcmp is BSD and it first appeard in 4.2BSD... it's not specific to GNU source but compat layer for BSD software.

Tue, Feb 19, 1:18 AM · Restricted Project, Restricted Project

Yesterday

krytarowski added inline comments to D42870: [lldb] [ObjectFile/ELF] Correct recognition of NetBSD images.
Mon, Feb 18, 10:54 AM · Restricted Project
krytarowski added inline comments to D42870: [lldb] [ObjectFile/ELF] Correct recognition of NetBSD images.
Mon, Feb 18, 10:26 AM · Restricted Project
krytarowski added inline comments to D42870: [lldb] [ObjectFile/ELF] Correct recognition of NetBSD images.
Mon, Feb 18, 10:25 AM · Restricted Project

Fri, Feb 15

krytarowski added a comment to D58230: [lldb] [MainLoop] Add kevent() EINTR handling.

@mgorny let's go through tech-kern@ and later checking FreeBSD/Darwin/OpenBSD. I think it's worth to clarify this in the documentation.

Fri, Feb 15, 12:09 AM · Restricted Project, Restricted Project

Thu, Feb 14

krytarowski added a comment to D58230: [lldb] [MainLoop] Add kevent() EINTR handling.

For EINTR we shall use llvm::sys::RetryAfterSignal

kevent() man page indicates:

All changes contained in the changelist are applied before any pending events are read from the queue.

Also:

[EINTR] A signal was delivered before the timeout expired and before any events were placed on the kqueue for return.

So while it's not stated explicitly, I think in_events is always consumed, even if EINTR is returned. In which case, llvm::sys::RetryAfterSignal would be wrong whenever in_events is not empty.

Thu, Feb 14, 3:07 PM · Restricted Project, Restricted Project
krytarowski accepted D58227: [lldb] [MainLoop] Remove redundant termination clause (NFCI).
Thu, Feb 14, 10:29 AM · Restricted Project, Restricted Project
krytarowski added a comment to D58227: [lldb] [MainLoop] Remove redundant termination clause (NFCI).

It looks good to me.

Thu, Feb 14, 7:34 AM · Restricted Project, Restricted Project
krytarowski accepted D58223: [lldb] [unittests] XFAIL two unittests failing on NetBSD.
Thu, Feb 14, 7:28 AM · Restricted Project
Herald added a project to D42206: If kevent() is interrupted by signal (or is being debugged) and we get EINTR, retry: Restricted Project.

'attaching a debugger produces an observable side-effect (EINTR) in the debugged process is considered a bug by the linux kernel folks'

Thu, Feb 14, 7:23 AM · Restricted Project, Restricted Project
krytarowski added a comment to D58230: [lldb] [MainLoop] Add kevent() EINTR handling.

For EINTR we shall use llvm::sys::RetryAfterSignal

Thu, Feb 14, 7:17 AM · Restricted Project, Restricted Project

Tue, Feb 12

krytarowski accepted D58131: [lldb] [unittest] Avoid mixing '127.0.0.1' and 'localhost'.

Short term this looks fine.

Tue, Feb 12, 9:23 AM · Restricted Project, Restricted Project

Sat, Feb 9

krytarowski committed rG61113341f714: Mark another test as flaky (authored by krytarowski).
Mark another test as flaky
Sat, Feb 9, 10:40 AM

Fri, Feb 8

krytarowski added a comment to D57959: [lldb] [MainLoop] Initialize empty sigset_t correctly.

But to what purpose? I think it's better to use consistent macros to refer to the same scenario.

Fri, Feb 8, 12:01 PM · Restricted Project
krytarowski added a comment to D57959: [lldb] [MainLoop] Initialize empty sigset_t correctly.

Ok, I see that _WIN32 actually redefines sigset_t, so I've added a separate branch for it.

Fri, Feb 8, 11:44 AM · Restricted Project
krytarowski added a comment to D57912: [lldb] [unittests] Disable MainLoopTest::DetectsEOF on NetBSD.

@labath our short-term goal is to enable execution of LLDB tests on the NetBSD buildbot. We are stuck temporarily with an older release of NetBSD on the machine for some time (1-2 months) so we need to live with it for now. No need to make it better than sufficient as of now.

Fri, Feb 8, 11:03 AM · Restricted Project, Restricted Project
krytarowski added inline comments to D57959: [lldb] [MainLoop] Initialize empty sigset_t correctly.
Fri, Feb 8, 11:00 AM · Restricted Project
krytarowski added a comment to D57959: [lldb] [MainLoop] Initialize empty sigset_t correctly.

I think that sigemptyset(2) is unsupported on Windows.

Fri, Feb 8, 11:00 AM · Restricted Project

Thu, Feb 7

krytarowski accepted D57907: lldb: Fix compilation on OpenBSD.
Thu, Feb 7, 7:45 PM · Restricted Project, Restricted Project
krytarowski accepted D57912: [lldb] [unittests] Disable MainLoopTest::DetectsEOF on NetBSD.
Thu, Feb 7, 1:33 PM · Restricted Project, Restricted Project

Tue, Feb 5

krytarowski committed rG3349bd662aad: Update the ioctl(2) list in sanitizers with NetBSD 8.99.34 (authored by krytarowski).
Update the ioctl(2) list in sanitizers with NetBSD 8.99.34
Tue, Feb 5, 2:23 PM

Sun, Feb 3

krytarowski updated subscribers of D57592: Replace uses of %T with %t in from previous frontend test differential .
Sun, Feb 3, 4:29 AM · Restricted Project, Restricted Project
krytarowski added a comment to D57592: Replace uses of %T with %t in from previous frontend test differential .

The NetBSD buildbot breaks in these tests now:

Sun, Feb 3, 4:29 AM · Restricted Project, Restricted Project

Sat, Feb 2

krytarowski added a reverting change for D44035: Support OpenBSD in common interceptors: rG980d0f891928: Revert D44035.
Sat, Feb 2, 5:43 AM

Fri, Feb 1

krytarowski added a comment to D57455: [libunwind] Provide inline placement new definition.

The NetBSD buildbot is affected and red for some time now.

Fri, Feb 1, 12:35 PM · Restricted Project

Wed, Jan 30

krytarowski added a comment to D56650: [lld] [ELF] Support customizing behavior on target triple.

chandlerc added a comment.

There was a long discussion between two NetBSD maintainers about this (both already in the reviewers list of this patch). I'm not sure if there is an existing thread that would be better to follow up on as opposed to starting a fresh thread.

Wed, Jan 30, 3:18 PM
krytarowski added a comment to D56650: [lld] [ELF] Support customizing behavior on target triple.

If you still need to patch GNU ld, it doesn't seems like this patch makes things easier for you. (But even if this would make it easier for you, this patch's approach is not okay by design though.)

Wed, Jan 30, 12:34 PM
krytarowski added a comment to D56650: [lld] [ELF] Support customizing behavior on target triple.

If we pass flags from clang, we sacrifice:

Wed, Jan 30, 12:09 PM
krytarowski added a reviewer for D56650: [lld] [ELF] Support customizing behavior on target triple: christos.
Wed, Jan 30, 9:28 AM
krytarowski added a comment to D56650: [lld] [ELF] Support customizing behavior on target triple.

@rui we need some resolution here. We have stronger feelings from the community to customize the linker directly based on detected triple.

Wed, Jan 30, 7:06 AM

Tue, Jan 29

krytarowski added a comment to D57412: [scudo] Initial standalone skeleton check-in.

I have got a scudo support patch for NetBSD locally.. but the original tests are havily prepared against GNU malloc. This makes me uncertain whether scudo really works. Are there plans to make the tests more generic?

That should be the case for the unit-tests. The new way things are done will clearly separate the C/C++ wrappers.
I can add you on the standalone check-ins for you to chime in on the direction we are headed to.
All the development efforts so far has targeted Linux/Android/Fuchsia, and I unfortunately have no BSD knowledge, but we are definitely open to contributions.
Initial check-ins will be Linux specific though since it's my workstation and that's what I am testing things against.

I wouldn't pursue work on your side on the current non-standalone Scudo, as the standalone version will be better (more performant, smaller memory footprint, etc) on all fronts.

Tue, Jan 29, 2:22 PM · Restricted Project, Restricted Project
krytarowski added a comment to D57412: [scudo] Initial standalone skeleton check-in.

I have got a scudo support patch for NetBSD locally.. but the original tests are havily prepared against GNU malloc. This makes me uncertain whether scudo really works. Are there plans to make the tests more generic?

Tue, Jan 29, 12:54 PM · Restricted Project, Restricted Project

Sun, Jan 27

krytarowski added a comment to D57303: [ToolChains] [NetBSD] Append -rpath for shared compiler-rt runtimes.

How do you resolve paths? Linker cache with registry of libraries?

DT_NEEDED aren't treated as paths, they are used as object names (keys); dynamic linker passes those to the loader service which is responsible for resolving them and returning back the corresponding memory objects.

Sun, Jan 27, 2:05 PM
krytarowski added a comment to D57303: [ToolChains] [NetBSD] Append -rpath for shared compiler-rt runtimes.

+ vitalybuka

Can we fix it for everybody? It's certainly not restricted to NetBSD.

As a point of reference, we use shared runtimes on Fuchsia but we don't use rpath so this is not something we want for every system.

Sun, Jan 27, 1:38 PM
krytarowski added a reviewer for D57303: [ToolChains] [NetBSD] Append -rpath for shared compiler-rt runtimes: vitalybuka.

Can we fix it for everybody? It's certainly not restricted to NetBSD.

Sun, Jan 27, 1:03 PM

Thu, Jan 24

krytarowski accepted D57193: [lldb] [Process/NetBSD] Add missing linkage to -lutil.
Thu, Jan 24, 2:18 PM
krytarowski added inline comments to D57179: Enhance support for NetBSD in SafeStack.
Thu, Jan 24, 1:39 PM · Restricted Project
krytarowski added inline comments to D57179: Enhance support for NetBSD in SafeStack.
Thu, Jan 24, 1:14 PM · Restricted Project
krytarowski added a comment to D57181: Fix XRayTest link on FreeBSD (and likely NetBSD too).

NetBSD is affected in the same way.

Thu, Jan 24, 12:53 PM
krytarowski created D57179: Enhance support for NetBSD in SafeStack.
Thu, Jan 24, 12:16 PM · Restricted Project

Mon, Jan 21

krytarowski added a comment to D56975: [Support] Reimplement getMainExecutable() using sysctl on NetBSD.

I'd really prefer to keep the argv[0] code as is. I'm not sure what that test case is supposed to do, but it seems quite questionable as "check" is not a valid language frontend nor a version suffix. It should not work.

Mon, Jan 21, 2:03 AM

Sun, Jan 20

krytarowski accepted D56976: [clang] [test] Pass -ccc-install-dir in mac compilation db test.
Sun, Jan 20, 5:51 AM
krytarowski accepted D56975: [Support] Reimplement getMainExecutable() using sysctl on NetBSD.
Sun, Jan 20, 5:17 AM

Jan 18 2019

krytarowski accepted D56937: [safestack] Add ThreadId type as uint64_t.
Jan 18 2019, 2:35 PM
krytarowski added inline comments to D56937: [safestack] Add ThreadId type as uint64_t.
Jan 18 2019, 2:22 PM

Jan 17 2019

krytarowski added inline comments to D56886: [safestack] Remove dependency of SafeStack on sanitizer_common.
Jan 17 2019, 9:07 PM

Jan 15 2019

krytarowski added inline comments to rL351189: [Sanitizer] Intercept sl_add api on FreeBSD/NetBSD.
Jan 15 2019, 4:12 AM

Jan 14 2019

krytarowski added inline comments to D56594: [asan] Add fallback for Thumb after r350139.
Jan 14 2019, 1:50 AM

Jan 11 2019

krytarowski added a comment to D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK.

What do you think about this new logic:

  1. specified -z execstack -> do not emit GNU STACK segment
  2. specified -z noexecstack -> emit GNU STACK segment
  3. no option specified -> detect findSection(".note.GNU-stack") (I might miss offhand some details here to be sure if it is reliable) 3.1. detected -> emit GNU STACK segment 3.2. not detected -> do not emit GNU STACK segment

    Additionally we will specify explicitly in the clang driver for Linux and FreeBSD -z noexecstack.

I think I don't like the very idea of using "marker sections" in input object files to change the linker behavior. That's too subtle and seems error-prone to me.

After thinking for a while, I started thinking that the first version of this patch is probably exactly what we want. I had been thinking that -z {no,}execstack and -z {no,}gnustack are four different options, but what we actually want to get is tri-state:

  • emit PT_GNU_STACK with RWX permission
  • emit PT_GNU_STACK with RW permission
  • do not emit PT_GNU_STACK

    So we could map them to -z {execstack,noexecstack,nognustack}, respectively, with default set to -z noexecstack. You guys can pass -z nognustack to the linker to tell the linker to not emit it at all. That's exactly this patch does.
Jan 11 2019, 8:23 PM
krytarowski added a comment to D56215: [lld] [ELF] Include default search paths for NetBSD driver.

To be honest, I don't think I would lgtm a patch that changes lld's default behavior depending on host/target only for NetBSD, and it seems like a NetBSD's issue rather than an lld's issue. As I said, could you please make an effort to pass the flags you need from the compiler driver to the linker just like other systems do? That is easy to do, doesn't hurt anyone, probably a good thing to do anyway as it makes options explicit rather than implicit, and solves at least most of the problems you have.

Jan 11 2019, 2:23 PM · lld
krytarowski added a comment to D56215: [lld] [ELF] Include default search paths for NetBSD driver.

Actually probably Linux MIPS used it and some proprietary OSes.. but we skip them for now. Only FreeBSD sets OSABI in lld and uses an emulation name detection hack. Once we will get merged TripleTarget detection we can switch it to use proper Triple check.

Jan 11 2019, 1:50 PM · lld
krytarowski added inline comments to D56215: [lld] [ELF] Include default search paths for NetBSD driver.
Jan 11 2019, 1:17 PM · lld
krytarowski added a comment to D56215: [lld] [ELF] Include default search paths for NetBSD driver.

@mgorny could you check if we can get crossbuilding functional for:

  • to !NetBSD from NetBSD
  • from !NetBSD to NetBSD.
  • from NetBSD/amd64 to NetBSD/aarch64

    I wonder whether it can work if we will keep using 'ld' file name for a linker.
Jan 11 2019, 1:15 PM · lld
krytarowski accepted D56607: [clang] [NetBSD] Enable additional sanitizer types.
Jan 11 2019, 1:13 PM
krytarowski added inline comments to D56594: [asan] Add fallback for Thumb after r350139.
Jan 11 2019, 11:28 AM
krytarowski added a comment to D56215: [lld] [ELF] Include default search paths for NetBSD driver.

@mgorny could you check if we can get crossbuilding functional for:

Jan 11 2019, 11:00 AM · lld
krytarowski added a comment to D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK.

@ruiu actually if we can get D56215 merged we will be able to tune it specifically for NetBSD (with if (Config->TargetTriple.isOSNetBSD()) {) and retain intact the current Linux-biased logic for everybody who deserves to use it.

Jan 11 2019, 10:53 AM
krytarowski added a parent revision for D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK: D56215: [lld] [ELF] Include default search paths for NetBSD driver.
Jan 11 2019, 10:50 AM
krytarowski added a child revision for D56215: [lld] [ELF] Include default search paths for NetBSD driver: D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK.
Jan 11 2019, 10:50 AM · lld
krytarowski added inline comments to D56215: [lld] [ELF] Include default search paths for NetBSD driver.
Jan 11 2019, 10:36 AM · lld
krytarowski added a comment to D56607: [clang] [NetBSD] Enable additional sanitizer types.

Please check these options in regression test-suite. There are also some missing entries and please add them too.

Jan 11 2019, 10:13 AM
krytarowski added inline comments to D56215: [lld] [ELF] Include default search paths for NetBSD driver.
Jan 11 2019, 10:09 AM · lld
krytarowski added inline comments to D56594: [asan] Add fallback for Thumb after r350139.
Jan 11 2019, 9:42 AM
krytarowski accepted D56594: [asan] Add fallback for Thumb after r350139.
Jan 11 2019, 9:04 AM

Jan 10 2019

krytarowski added a comment to D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK.

What do you think about this new logic:

Jan 10 2019, 4:24 PM
krytarowski added a comment to D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK.

I understand the concerns, but lld is biased with being a Linux linker. We need to customize it (restore defaults?) for NetBSD.

Jan 10 2019, 3:58 PM
krytarowski added a comment to D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK.

Shouldn't the logic of emitting/not-emitting be based on findSection(".note.GNU-stack")? @mgorny can you please investigate it?

Jan 10 2019, 3:56 PM
krytarowski added a comment to D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK.

Actually looking at GNU ld(1) source code, the logic is a little bit more complex and it depends on more aspects like relocations.

Jan 10 2019, 3:53 PM
krytarowski added a comment to D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK.

The absence of PT_GNU_STACK segment makes stack area executable on systems that recognizes PT_GNU_STACK segment. So, I think if -z execstack is specified, we should omit PT_GNU_STACK segment rather than adding it, which I think you guys want. If we do that, it seems -z nognustack is a redundant option. That option name is unfortunate (you don't really mean you want an executable stack area), but that's I think still better than adding an option that is very similar to an existing feature.

If we are going to change the meaning of -z execstack, can we rename the option in lld? Probably to -z gnustack vs -z nognustack, probably there is no other use-case than RWX->RW protection change.

Both -z execstack and -z noexecstack are supported by GNU linkers, so we can't simply rename them. We might be able to define aliases to the options. But I'm not sure if we want it if the only reason to do so is aesthetic reason.

Jan 10 2019, 3:46 PM
krytarowski added a comment to D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK.

The absence of PT_GNU_STACK segment makes stack area executable on systems that recognizes PT_GNU_STACK segment. So, I think if -z execstack is specified, we should omit PT_GNU_STACK segment rather than adding it, which I think you guys want. If we do that, it seems -z nognustack is a redundant option. That option name is unfortunate (you don't really mean you want an executable stack area), but that's I think still better than adding an option that is very similar to an existing feature.

Jan 10 2019, 3:15 PM
krytarowski added inline comments to D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK.
Jan 10 2019, 12:18 PM
krytarowski added inline comments to D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK.
Jan 10 2019, 12:14 PM
krytarowski added a comment to D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK.

Looks good, we don't GNU STACK on NetBSD.

Jan 10 2019, 12:07 PM
krytarowski added inline comments to D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK.
Jan 10 2019, 12:06 PM
krytarowski added a comment to D56215: [lld] [ELF] Include default search paths for NetBSD driver.

@joerg if you think that this patch is OK, please click accept so we can be aware that this is what you want.

Jan 10 2019, 8:48 AM · lld

Jan 9 2019

krytarowski accepted D56495: [Sanitizer] Enable pututxline interception.
Jan 9 2019, 5:14 PM
krytarowski accepted D56109: [sanitizer_common] Define __sanitizer_FILE on NetBSD.
Jan 9 2019, 1:26 PM
krytarowski added inline comments to D56495: [Sanitizer] Enable pututxline interception.
Jan 9 2019, 9:23 AM

Jan 8 2019

krytarowski added inline comments to D56215: [lld] [ELF] Include default search paths for NetBSD driver.
Jan 8 2019, 4:20 PM · lld
krytarowski added a comment to D56215: [lld] [ELF] Include default search paths for NetBSD driver.

Thanks, this looks like a good starting point.

Jan 8 2019, 1:34 PM · lld

Jan 7 2019

krytarowski added a comment to D56141: [asan] Support running without /proc.

Can we handle with this change a similar scenario that proc map is too large to be retrieved? If so can we generalize no-/proc to no-memorymap?

Does this look like an error return from internal_sysctl in ReadProcMaps? Sure, we can mock that condition with the same flag.

Jan 7 2019, 12:41 PM
krytarowski added a comment to D56288: [ELF] Do not enable 'new dtags' on NetBSD by default.

On NetBSD the 'new' semantics was already implemented with 'old' RPATH. I don't know the timing whether there already existed RUNPATH, but the result is that we never implemented it and never needed it. The core of NetBSD was convinced to add an alias as it was very difficult in some examples (probably due to Rust) to rollback to 'old' RPATH.

Jan 7 2019, 12:28 PM
krytarowski added a comment to D56288: [ELF] Do not enable 'new dtags' on NetBSD by default.

Ok, maybe I'm being silly but since clang driver has to pass --enable-new-dtags for GNU ld compatibility anyway, wouldn't it make sense to keep the default as disabled in order to match GNU ld behavior?

Jan 7 2019, 6:18 AM

Jan 6 2019

krytarowski added a comment to D56064: More tolerance for flaky tests in libc++ on NetBSD.

I'm going to revert it soon and see what happens. Please keep an eye on http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd8

I was receiving complains from other developers about flakiness.

Were the complaints about the lldb-amd64-ninja-netbsd8 bot specifically? Because if the tests are flaky on all NetBSD system, regardless of hardware and load, then we should find out why.
If it's just the one bot under load, we should target our fix to that.

Jan 6 2019, 6:12 AM

Jan 5 2019

krytarowski added a comment to D56215: [lld] [ELF] Include default search paths for NetBSD driver.

I've grepped FreeBSD, OpenBSD and pkgsrc.

Jan 5 2019, 12:26 PM · lld
krytarowski added a comment to D56064: More tolerance for flaky tests in libc++ on NetBSD.

Reverted in r350477.

Jan 5 2019, 12:15 PM
krytarowski added a comment to D56064: More tolerance for flaky tests in libc++ on NetBSD.

I'm going to revert it soon and see what happens. Please keep an eye on http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd8

Jan 5 2019, 12:09 PM
krytarowski added a comment to D56064: More tolerance for flaky tests in libc++ on NetBSD.

I would rather revert this, and fix the flaky tests. And if there are flaky tests that aren't marked flaky then we need to do that.

Jan 5 2019, 11:44 AM

Jan 4 2019

krytarowski added a comment to D56215: [lld] [ELF] Include default search paths for NetBSD driver.

For the record, another option is to actually fix other software not to call LD directly.

Or if you really need to call the linker directly without specifying search paths you could also install a shell script as /usr/bin/ld that passes the appropriate flags to /usr/bin/ld.lld?

I don't think ifdefs in the source code are a good idea. Cross linking should just work as expected. But you could look at the OS field in the first input ELF file to choose default config options/a different emulation for NetBSD.

The approach we are using in CheriBSD to differentiate between MIPS and CHERI pure-capability to either pass an explicitly -m elf_btsmip_cheri_fbsd/ -m elf_btsmip_fbsd or infer whether it is CHERI or MIPS based on the e_flags field of the first input file.

Jan 4 2019, 9:54 AM · lld

Jan 3 2019

krytarowski added a comment to D56215: [lld] [ELF] Include default search paths for NetBSD driver.

Not sure what I understand the point, but as to make lld work on/for NetBSD, I wonder if you can just add -L<path> to the command line in the compiler driver. Isn't a NetBSD triple passed to the compiler driver? If so, I wonder if you can add a few extra options when invoking the linker.

Jan 3 2019, 3:37 PM · lld
krytarowski added a comment to D56215: [lld] [ELF] Include default search paths for NetBSD driver.

Actually I think that we can handle two cases witch a combination of proposals:

  • native mode
  • cross mode
Jan 3 2019, 2:56 PM · lld
krytarowski added a comment to D56215: [lld] [ELF] Include default search paths for NetBSD driver.

Talking from the perspective of having had to deal with thousands of packages in pkgsrc over the years: it is naive to believe that there isn't a lot of software that calls the linker directly for various reasons. As such, it is very important to have a useful configuration in the linker by default. Such a configuration is by its very nature target specific. This doesn't mean it can't be done in a cross-compiler friendly way, on the contrary. Over the years NetBSD has been pushing its toolchain to be as similar for the native build and a cross-target as reasonable possible. Modulo the build time choices in the config.h sense, the only difference between the native and cross tools is the built-in default of the former.

It might be naive but I don't think it's too naive. Most programs use ld via cc, and I don't think it is too unreasonable to not implement a host-specific logic for a very small percentage of programs that directly use ld. If we do, that logic would be the same or very similar to the one that we already have in cc. I think we should avoid that duplication of the host-specific config in the toolchain.

I see there are pros and cons to not have host-specific config in ld. That said, if other operating systems can live without host-specific config in lld, why can't NetBSD do? I really don't like to be in a situation where only one operating system have a host-specific config while others don't.

Jan 3 2019, 2:42 PM · lld
krytarowski added a comment to D56215: [lld] [ELF] Include default search paths for NetBSD driver.
On 03.01.2019 23:15, Joerg Sonnenberger wrote:
> On Thu, Jan 03, 2019 at 09:38:49PM +0000, Kamil Rytarowski via Phabricator via cfe-commits wrote:
>> I think that this place is not the right place to bash GNU ld for performance issues.
> 
> I didn't.
> 
>> I will refer just to slides and paper from Ian Lance Taylor to get overview why it is unacceptably slow:
>>
>> https://www.airs.com/ian/gold-slides.pdf
>> https://ai.google/research/pubs/pub34417.pdf
> 
> We all know that gold and lld are faster. It's a huge step from
> "somewhat faster" to "unacceptably slow". But that's again a completely
> separate topic.
Jan 3 2019, 2:20 PM · lld
krytarowski added a comment to D56215: [lld] [ELF] Include default search paths for NetBSD driver.

On Thu, Jan 03, 2019 at 08:31:53PM +0000, Kamil Rytarowski via Phabricator via cfe-commits wrote:

krytarowski added a comment.

On 03.01.2019 21:19, Joerg Sonnenberger wrote:

On Thu, Jan 03, 2019 at 06:34:22PM +0000, Kamil Rytarowski via Phabricator via cfe-commits wrote:

krytarowski added a comment.

Actually I find it frustrating and unfair as GNU ld doesn't have builtin

knowledge either.. it's passed with gross 'super hack' comments from build scripts... but we are forced to push it to lld in order to move on.

I'm puzzled. Seriously, when was the last time you actually checked how

much customization contains on a per-OS base in GNU ld? Yes, I'm
including the various build scripts because GNU ld is generally build by
a mix of hard-coded logic in the tool itself and various adjustments in
the linker scripts it is shipped with. But they are all a builtin part
of GNU ld as far as the end user is concerned. It is pretty much
irrelevant from a point of functionality where that logic is, but
skipping is a serious usability issue.

Joerg

I'm referring to code '/usr/src/external/gpl3/binutils/usr.bin/ld/Makefile':

Jan 3 2019, 1:38 PM · lld
krytarowski added a comment to D56215: [lld] [ELF] Include default search paths for NetBSD driver.

I think that ifdefining the linker options with __NetBSD__ is no-go.

Jan 3 2019, 1:26 PM · lld
krytarowski added a comment to D56288: [ELF] Do not enable 'new dtags' on NetBSD by default.

We want to keep it disabled by default on NetBSD.. but it would be to keep dynamic detection of target NetBSD rather than hardcoded ifdef.

Jan 3 2019, 12:41 PM
krytarowski added a comment to D56215: [lld] [ELF] Include default search paths for NetBSD driver.

On 03.01.2019 21:19, Joerg Sonnenberger wrote:

On Thu, Jan 03, 2019 at 06:34:22PM +0000, Kamil Rytarowski via Phabricator via cfe-commits wrote:

krytarowski added a comment.

Actually I find it frustrating and unfair as GNU ld doesn't have builtin
knowledge either.. it's passed with gross 'super hack' comments from build scripts... but we are forced to push it to lld in order to move on.

I'm puzzled. Seriously, when was the last time you actually checked how
much customization contains on a per-OS base in GNU ld? Yes, I'm
including the various build scripts because GNU ld is generally build by
a mix of hard-coded logic in the tool itself and various adjustments in
the linker scripts it is shipped with. But they are all a builtin part
of GNU ld as far as the end user is concerned. It is pretty much
irrelevant from a point of functionality where that logic is, but
skipping is a serious usability issue.

Joerg

I'm referring to code '/usr/src/external/gpl3/binutils/usr.bin/ld/Makefile':

Jan 3 2019, 12:31 PM · lld