- User Since
- Jul 24 2013, 5:36 AM (238 w, 6 d)
In FreeBSD libpthread.so is a symlink to libthr; -pthread and -lpthread should both work.
Fri, Feb 16
Fri, Feb 9
Thu, Feb 8
Wed, Feb 7
Thanks, I'll commit this later today. Not sure how I ended up with 01 instead of O1 but have fixed those locally.
PDF version of current version:
- more feedback from review
- incorporated doc updates for -z from https://reviews.freebsd.org/D14220
Tue, Feb 6
PDF rendered version of the man page:
Incorporate review feedback
- Update copyright and license statement
- Remove internal -full-shutdown option
Fri, Jan 26
Thu, Jan 25
Jan 11 2018
Seems fine to me
Jan 10 2018
The title is more correctly "non-Apple hosts"? I.e., building on FreeBSD will also use llvm-objcopy.
Jan 4 2018
Is there any plan (or willingness?) to backport this further, to 4.0.0 and even 3.4.1?
Dec 29 2017
With this patch applied Kostik's original testcase passes.
Dec 26 2017
The original FreeBSD test case (a 'hello world' linked with lld -znotext) works with this change applied.
Dec 25 2017
Dec 24 2017
Dec 23 2017
This LGTM, I had a similar change in my repo while trying to fix PR35720.
Dec 22 2017
I can confirm this fixes the reduced test case, but the 'hello world' test on FreeBSD still fails, now with:
Dec 20 2017
Dec 18 2017
Dec 13 2017
FWIW our standard readelf in FreeBSD comes from the ELF Tool Chain project and doesn't have the warning. It's only when the GNU readelf package is installed that we'd encounter this.
Dec 11 2017
Dec 10 2017
From e-mail followup @dim linked against libc linked with pre-patch lld.
Dec 9 2017
I successfully linked all of FreeBSD/amd64 with LLD head + this patch.
Dec 8 2017
Spoke too soon - buildworld is actually failing elsewhere now, with my backported patch in lld.
/usr/obj/usr/home/emaste/src/freebsd/amd64.amd64/tmp/usr/bin/ld: error: relocation R_X86_64_PLT32 cannot refer to absolute symbol: __tls_get_addr >>> defined in <internal> >>> referenced by runetype.h:98 (/usr/obj/usr/home/emaste/src/freebsd/amd64.amd64/tmp/usr/include/runetype.h:98) >>> xlat16_iconv.pico:(kiconv_xlat16_open)
I probably have an error in my backport attempt though, this other library (lib/libkiconv) linked succesfully with lld head + this patch.
I tested this patch against lld head and confirm it resolves the issue via my reproducer. I also backported it to lld 5.0.1 (the version in FreeBSD HEAD) , rebuilt, and confirm that sbrk() is functional.
Nov 20 2017
Nov 4 2017
Oct 31 2017
Thanks for including the steps you used to effect the mechanical change! Having maintained long-lived derived branches of open source projects in the past I've found that sort of thing very helpful.
Oct 14 2017
Oct 13 2017
Oct 6 2017
Oct 2 2017
Sep 30 2017
I realized I don't have my LLVM SVN creds on my laptop, so will commit this when I return home in a couple of days if it's still not done.
Sep 27 2017
Sep 16 2017
Very small nit noticed on another look: there are couple of instances of Mib that should be MiB
Sep 13 2017
Sep 2 2017
Testing this just now I got:
FAIL: LLDB (/usr/bin/cc-x86_64) :: test_attach_to_process_from_different_dir_by_id (TestProcessAttach.ProcessAttachTestCase) ====================================================================== ERROR: test_attach_to_process_from_different_dir_by_id (TestProcessAttach.ProcessAttachTestCase) Test attach by process id ---------------------------------------------------------------------- Traceback (most recent call last): File "/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/process_attach/TestProcessAttach.py", line 44, in test_attach_to_process_from_different_dir_by_id os.mkdir(os.path.join(os.getcwd(),'newdir')) OSError: [Errno 17] File exists: '/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/process_attach/newdir' Config=x86_64-/usr/bin/cc
Aug 25 2017
Aug 18 2017
We also face this problem on FreeBSD/mips64 when trying to link with lld.
(Aside, for FreeBSD we are rather eager to have this support arrive in lld upstream and will from there backport it to the lld 5.0.0 in our src tree. As it stands we cannot link the full base system with lld because lldb has grown too large -- https://bugs.freebsd.org/215691)
Aug 17 2017
Thank you, this will be quite useful for FreeBSD and the change seems reasonable to me.
Aug 16 2017
Aug 13 2017
Ping for two open questions
Aug 10 2017
Aug 9 2017
Still would appreciate diffs uploaded with full context - i.e.,
Note that you can upload patches created through various diff tools, including git and svn. To make reviews easier, please always include as much context as possible with your diff! Don’t worry, Phabricator will automatically send a diff with a smaller context in the review email, but having the full file in the web interface will help the reviewer understand your code.
Adding the comment above the list seems like a good idea to me.
I've committed this to FreeBSD's copy of lldb in r322326. @labath if you're happy with this patch I will commit to lldb for @karnajitw. I'm not sure how the patch ended up with a conflict, but it's just a whitespace issue.
Aug 8 2017
Actually, I think you probably need to extend the @skipIfLinux to apply to freebsd as well.
Aug 7 2017
With this patch i386 test results are comparable to amd64, and I'm happy with it from a FreeBSD perspective (modulo the PlatformOpenBSD patch conflict).
The change in PlatformOpenBSD.cpp failed to apply for me (although it was trivial to manually apply it).