Re: [CFT] Update to clang 3.4

2014-01-07 Thread Ed Maste
On 7 January 2014 03:54, David Chisnall  wrote:
> On 7 Jan 2014, at 06:49, Rui Paulo  wrote:
>> Our libdwarf was a from scratch implementation and we never used the LGPL 
>> libdwarf.  I don't know if it's worth investing time upgrading our BSD 
>> licenced libdwarf or importing the LGPL libdwarf.  Given the push to keep 
>> the tree mostly BSD licenced, I would say the former.

I think bringing in a later version of elftoolchain / libdwarf would
be straightforward.  It seems there would be a fair amount of work
left even after doing that though.  Specifically, there's a todo item
for "Add support for DWARF4 ".debug_types" section":
sourceforge.net/apps/trac/elftoolchain/ticket/408.  There's still
ongoing development in elftoolchain, but I have no idea how likely it
is that a usable libdwarf will appear in the near future.  Perhaps
kaiw@ or jkoshy@ can comment.

> LLVM now has fairly complete DRAWF4 parsing support.  What interfaces do the 
> ctf tools need, and are they the only consumers of libdwarf?

The ctf tools are indeed the only consumers of libdwarf, and all use
is in one file: cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c.  It
looks like it just parses various DW_TAG types (array, enum, pointer,
...) from .debug_info, and migrating to an LLVM DWARF parser wouldn't
be overly difficult.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: [CFT] Update to clang 3.4

2014-01-07 Thread Ed Maste
On 5 January 2014 08:00, Dimitry Andric  wrote:
>
> Second, the shipped version of gdb in our tree is very old, and is
> basically unmaintained.  Nobody in their right mind should ever use it
> for debugging, unless they have no other choice.  As soon as the in-tree
> version of lldb is in workable state, we should get rid of the base gdb.
>
> I think the only tricky task left is our custom kgdb hacks, which must
> be ported to some newer version of gdb soon, or preferably to lldb.  I
> have no idea if anybody is working on those.

Our in-tree gdb is not particularly useful, but it also supports some
debug information that both the ports gdb and upstream gdb do not.  I
am unaware of anyone working on bringing those changes and kgdb
support to the ports gdb; I don't expect I'll be able to.

I will work on LLDB kernel debugging support although I don't have a
specific timeline yet.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: abi::__cxa_demangle provides invalid result on non-mangled symbols

2014-06-09 Thread Ed Maste
On 9 June 2014 21:48, Ryan Stone  wrote:
> abi::__cxa_demangle is giving me an invalid result if I pass it a
> symbol that is not mangled.  This is causing me problems as in my
> application, I'm getting symbol names from libelf and have no way of
> know a priori whether a symbol is mangled or not.

I had the same issue in LLVM, and as hacky as it seems, the solution
is to check that the name starts with "_Z" before passing it to
__cxa_demangle.

For reference the LLVM review for the change is here:
http://reviews.llvm.org/D2552

I didn't get around to testing it on Linux; since you have a test
application ready it would be interesting to see the result of
__cxa_demangle("f") there.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming?

2014-06-11 Thread Ed Maste
On 11 June 2014 14:53, Craig Rodrigues  wrote:
>
> Is anyone working on a kernel lldb?  When is it expected to be ready?

Kernel LLDB support is an ongoing Summer of Code project this year.
I'm not sure it's feasible for 10.1 though.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: abi::__cxa_demangle provides invalid result on non-mangled symbols

2014-06-11 Thread Ed Maste
On 10 June 2014 02:38, David Chisnall  wrote:
>
> If you know that the thing that you are demangling is a symbol name, then you 
> can use the _Z check, which isn't really a hack - it's a marker added to 
> identify C++ symbols.  Note that, if you're writing portable code, you need 
> to remember that some systems prepend an underscore to all compiler-generated 
> symbols, so you may also need to check for __Z and trim the leading _.

Right, it just feels hackish to have to know this detail of the ABI.
I think I'd like an explicit __cxa_demangle_symbol interface, or
perhaps __cxa_is_mangled_symbol to query a string.

> The __cxa_demangle() function has to handle things that are not just symbols 
> (types and so on) and so can't do this test itself.  Its most common use is 
> generating a human-friendly error for an uncaught exception, where it is just 
> parsing a type encoding.

My use, and I suspect Ryan's, is demangling symbols obtained from
introspection interfaces like backtrace_symbols(3).

In any case, our libelftc __cxa_demangle accepts strings that are
neither symbols nor NTBS manglings, and can return a bogus demangled
name for them.  Of course, it's a mistake to rely on __cxa_demangle
rejecting these for arbitrary input.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Using more elftoolchain tools?

2014-11-27 Thread Ed Maste
On 23 November 2014 at 19:09, Baptiste Daroussin  wrote:
> Hi all,
>
> From what I can see on the elftoolchain website, they do have working
> replacement for:
> - size(1)
> - addr2line(1)
> - strings(1)
> - nm(1)
> - strip(1)
>
> Does anyone knows if there are known issues with those? or if they are viable
> replacement for the version we have in base?
>
> I'm planning to spend a bit of time on those (I think emaste@ is already 
> working
> on strip(1) so I'll skip that one).

I'll save you the effort, since it was easy to add the rest after
getting the first one incorporated into our build.

The set above are in code review at https://reviews.freebsd.org/D1224.
It adds a WITH_ELFTOOLCHAIN_TOOLS knob to enable building them instead
of binutils. I have a -current VM built with that enabled and it
passes basic sanity tests.

I know that at elftoolchain is missing some required functionality for
MIPS at least, but I don't think it'll be hard to add. What I'd like
to do is commit the change in D1224 after a little more refinement,
then call for broader testing and a ports exp run. We can enable
WITH_ELFTOOLCHAIN_TOOLS by default on a per-architecture basis until
it works properly everywhere.

-Ed
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Migration to dynamic libs for llvm and clang

2014-12-16 Thread Ed Maste
One of goals for the toolchain prior to the FreeBSD 11 branch is to
create a libllvm.so and libclang.so for use by all of the LLVM family
tools installed in the base system. This message is just a heads-up in
case anyone has questions or comments on the idea.

We currently build a large number of static libs for the llvm and
clang components, which are reused in a number of tools in the LLVM
family. The resulting binaries end up quite large, and as a group
require a lot of disk space. For example, LLDB includes a copy of
Clang, used as its expression parser.  As a result, on my desktop
/usr/bin/clang and /usr/bin/lldb are both 27MB.

Over time we may add additional LLVM family tools (e.g.,
llvm-objdump), and this will help avoid excessive bloat as we do so.

I expect libllvm.so and libclang.so will go in /usr/lib/private.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Migration to dynamic libs for llvm and clang

2014-12-16 Thread Ed Maste
On 16 December 2014 at 11:15, David Chisnall  wrote:
>
> Upstream doesn't call it libclang (that's the name of the library with a 
> stable C ABI, which is why I'd like us not to confuse it with something with 
> a library with an unstable C++ API). They do produce a libLLVM.so from the 
> LLVM builds and work is underway to have shared library builds for clang.

Agreed. Even if there's no potential issue since it will be in
/usr/lib/private it would be confusing. David's suggestion of libcfe
sounds reasonable.

>> That said, I agree with the general idea, but one of the first things
>> we should decide is whether this will be optional or not.  Having to
>> maintain yet another WITH_CLANG_FOO option is burdensome...

Fair enough, I'd definitely like to see fewer build-time knobs over
time, not more.

> I agree.  I'd quite like to see performance numbers for the compiler.  I 
> think I saw about a 10% overhead for buildworld last time I tried, but that 
> was a couple of years ago.

Ok. I will put this together in a branch and we can compare results
and decide which way to go when we have actual numbers.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Migration to dynamic libs for llvm and clang

2014-12-16 Thread Ed Maste
On 16 December 2014 at 12:39, Warner Losh  wrote:
>
> We should defer testing until after that import :)

Indeed. I have an early WIP patch in a local branch, but any new work
before 3.5.x lands will be wasted, so it will be in the new year that
I'll have something to start testing.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Migration to dynamic libs for llvm and clang

2014-12-16 Thread Ed Maste
On 16 December 2014 at 14:47, Warner Losh  wrote:
>
> My comment was
> more to Ed’s notion that these numbers will be dropping any time soon.

To be clear, I don't expect we'll be dropping knobs soon. We should
keep that as a goal to aim for.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Call for testing: elftoolchain tools

2014-12-18 Thread Ed Maste
We have a rather outdated version of binutils in the base system.  As
part of a project to update our toolchain I've started working on
using some of the tools from the elftoolchain project.  There is now a
build knob to enable the use of the following tools:

* addr2line
* elfcopy (strip)
* nm
* size
* strings

The knob (in /etc/src.conf) is:
WITH_ELFTOOLCHAIN_TOOLS=yes

The binutils version is still used for as, ld, objcopy, objdump and
readelf; future projects will handle these.

The option is being tested in ports exp-runs on amd64 and i386, and
has had basic sanity testing on arm64 and mips64.

I'm interested in test reports across a variety of hardware
architectures and use cases.  If everything works as expected you
should see no difference -- the tools should be drop-in replacements.

-Ed
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0

2015-01-08 Thread Ed Maste
On 8 January 2015 at 08:45, Craig Rodrigues  wrote:
> I just tried to build CURRENT with WITH_LLDB=yes
> in /etc/make.conf.  I got this error:
>
> ...

Thanks for the report Craig, I'm looking at it.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Compiling LLDB

2015-03-30 Thread Ed Maste
On 30 March 2015 at 19:18, Kenan Ali  wrote:
> Hi,
>
> I would like to see if I could get involved with contributing to the kernel 
> core support for LLDB under FreeBSD. I'm running a FreeBSD-head build (on a 
> VM) from a week or two ago, and I'm following the instructions from here: 
> https://wiki.freebsd.org/lldb
>
> Once I get to the 'ninja lldb' step, it seems that I always end up with the 
> following error:
>
> CC: error: unable to execute command: Killed
> CC: error: linker command failed due to signal (use -v to see invocation)
> Ninja: build stopped: subcommand failed.
>
> I've tried passing the '-v' flag to ninja, which lists a large invocation 
> before spewing out the errors above. However, I cannot seem to figure out how 
> to get the '-v' command passed to LLVM's linker. Neither ninja's help output 
> or some basic Googling seem to be helping me diagnose this issue, so I was 
> wondering if anyone here could help?

I'd suggest checking /var/log/messages for further information. Is
this i386 or amd64, how much memory does your build host have, and are
you compiling with debug information or no? If had to guess, you're
running out of memory (or running into ulimit) during linking, and the
process is being killed as a result.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: profile_rt from llvm folks?

2015-04-01 Thread Ed Maste
On 1 April 2015 at 16:35, Dimitry Andric  wrote:
> On 01 Apr 2015, at 02:03, NGie Cooper  wrote:
>>
>> Hi all,
>>We've recently integrated a version of profile_rt from the llvm
>> folks internally to replace gcov for code coverage. I was wondering if
>> there was a plan to replace the copy of gcov in FreeBSD with the same
>> (either in the base system, ports, or both).
>
> I personally have no plans to do so, but the build of libprofile_rt.a
> was added in r276857, at least.

Yes, as of that change one can compile with --coverage, and .gcda and
.gcno files will be produced via the functionality in libprofile_rt.a.

gcov(1) is able to use them, but when I tried llvm-cov it didn't work
correctly; in any case, llvm-cov is now on the roadmap for our
toolchain.

-Ed
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Failed to build rescue with gcc 4.9

2015-04-03 Thread Ed Maste
On 3 April 2015 at 13:02, Warner Losh  wrote:
> That shows that something in the list is needed. Likely only crunchhide.
>
> It doesn’t tell us why we need it, or when we started needing it, or what
> other conditions we might need it. This information is critical to document
> so we know when we can stop doing it in the future. I’m extremely reluctant
> to commit this until we know these details.

Yes, it's crunchide. It was broken prior to r277259:

|crunchide: Correct 64-bit section header offset
|
|For 64-bit binaries the Elf_Ehdr e_shoff is at offset 40, not 44.
|Instead of using an incorrect hardcoded offset, let the compiler
|figure it out for us with offsetof().
|
|Differential Revision: https://reviews.freebsd.org/D1543

It's not completely clear to me why we did not encounter this before;
a comment before the erroneous write states:

/*
 * update the offset of section header table in elf
 * header if needed.
*/

so I presume something about the object file created by gcc 4.9 causes
this code to be executed, while builds using the in-tree compiler did
not.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: clang confuses kgdb on static symbols

2015-10-20 Thread Ed Maste
On 20 October 2015 at 13:27, John Baldwin  wrote:
>
> If '-gdwarf-4' works then you can just set that in the DEBUG makeoptions as a
> test, otherwise try hacking kern.mk to disable this bit:
>
> #
> # Add -gdwarf-2 when compiling -g. The default starting in clang v3.4
> # and gcc 4.8 is to generate DWARF version 4. However, our tools don't
> # cope well with DWARF 4, so force it to genereate DWARF2, which they
> # understand. Do this unconditionally as it is harmless when not needed,
> # but critical for these newer versions.
> #
> .if ${CFLAGS:M-g} != "" && ${CFLAGS:M-gdwarf*} == ""
> CFLAGS+=-gdwarf-2
> .endif

Note that Clang defaults to DWARF 2 on FreeBSD, so removing the
override in kern.mk isn't sufficient.

>From contrib/llvm/tools/clang/lib/Driver/Tools.cpp:
else if (!A->getOption().matches(options::OPT_g0) &&
 !A->getOption().matches(options::OPT_ggdb0)) {
  // Default is dwarf-2 for Darwin, OpenBSD, FreeBSD and Solaris.
  const llvm::Triple &Triple = getToolChain().getTriple();
  if (Triple.isOSDarwin() || Triple.getOS() == llvm::Triple::OpenBSD ||
  Triple.getOS() == llvm::Triple::FreeBSD ||
  Triple.getOS() == llvm::Triple::Solaris)
CmdArgs.push_back("-gdwarf-2");
  else
CmdArgs.push_back("-g");
}

It may be time for us to remove this default from Clang.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: clang confuses kgdb on static symbols

2015-10-20 Thread Ed Maste
On 20 October 2015 at 15:55, Konstantin Belousov  wrote:
>
> We cannot stop generating dwarf-2 until in tree gdb and kgdb are substituted
> by a working replacement.

Note that I'm only suggesting removing the baked-in default from
Clang, not the setting in kern.mk.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: clang confuses kgdb on static symbols

2015-10-20 Thread Ed Maste
On 20 October 2015 at 16:30, Konstantin Belousov  wrote:
>
> Wouldn't this cause another outburst of 'works by default' discussion
> from some other place ?

Ok, I'll hold off on this until we make progress on the gdb retirement plan.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: clang confuses kgdb on static symbols

2015-10-20 Thread Ed Maste
On 20 October 2015 at 17:18, Warner Losh  wrote:
>
>> On Oct 20, 2015, at 3:07 PM, Ed Maste  wrote:
>>
>> On 20 October 2015 at 16:30, Konstantin Belousov  wrote:
>>>
>>> Wouldn't this cause another outburst of 'works by default' discussion
>>> from some other place ?
>>
>> Ok, I'll hold off on this until we make progress on the gdb retirement plan.
>
> Have the issues with ctfconvert been fixed that caused us to go
> to dwarf2 by default?

It should be - kaiw imported a new libdwarf when this first came up to
pick up new DWARF support. It had a few outstanding issues, but those
should now be fixed with my elftoolchain update in r276371 last
December.

Testing that support is of course one of the prerequisites for
changing the default back to DWARF 4.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: LLDB build failure

2016-07-19 Thread Ed Maste
On 19 July 2016 at 13:40, Jonathan Anderson  wrote:
> Hello toolchain@,
>
> When building a recent (r275944) LLDB on stable/11, I've encountered build
> failures in tools/lldb-mi (missing symbol llvm_regexec, need to link against
> LLVMSupport). This problem doesn't occur on (at least) OS X, so perhaps the
> LLVM build bots don't see it.

We have a FreeBSD 11 LLDB build bot, which was green as of r272672:
http://lab.llvm.org:8011/builders/lldb-amd64-ninja-freebsd11
although I'm not certain exactly what it tests. I build regularly on
my stable/10 desktop though and lldb-mi built successfully.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Update on using LLVM's lld linker in the FreeBSD base system

2016-08-01 Thread Ed Maste
Over the past year or so I have been investigating the state of LLVM's
lld linker for use in the FreeBSD base system, to see if it could be
used as FreeBSD's system linker.

Why do we need a new linker? Compared to the GNU ld 2.17.50 that we
have in the FreeBSD base system, lld will bring:

* AArch64 (arm64) support
* Link Time Optimization (LTO)
* New ABI support
* Other linker optimization
* Much faster link times
* Maintained code base

I've posted a couple of status updates on the LLVM mailing list:
http://lists.llvm.org/pipermail/llvm-dev/2015-November/092572.html
http://lists.llvm.org/pipermail/llvm-dev/2016-March/096449.html

Since the last update in March several lld developers have implemented
much of the missing functionality. The main blockers were symbol
version support and expression evaluation in the linker script
expression parser. Both are now nearly complete.

There are a few features used by the FreeBSD base system that lld
developers (intentionally) do not expect to implement, unless they're
reasonably widely used in a variety of different software. If they're
not implemented we can modify FreeBSD to avoid using them. I'm aware
of:

-N/--omagic, used by some boot loader components. We can achieve the
same effect with a linker script.

-dc, used by the rescue build. As long as object files are built
specifically for rescue we can probably use -fno-common instead.

-r binary to convert binary files into ELF objects, used by some
device drivers in kernel and module builds. We can use
objcopy(elfcopy) instead.

Davide Italiano and Rafael Ávila de Espíndola presented an update on
the state of lld at BSDCan 2016:
https://www.bsdcan.org/2016/schedule/events/656.en.html

At this point I'm confident that lld is going to be a viable linker
for the FreeBSD base system, and am beginning to plan its import.

I expect the process will look something like this:

1. Update lld along with the Clang/LLVM 3.9 update that dim@ is working on.
2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld
on the same architectures that use Clang (amd64, arm, arm64, i386). I
don't think there's a need for a WITH_LLD src.conf knob, but will add
one if desired.
3. Update lld again (most likely to a snapshot from upstream SVN) once
it is able to link an unmodified FreeBSD kernel.
4. Modify the boot loader and kernel builds to avoid using features
not implemented by lld.
5. Introduce a WITH_LLD_AS_LD knob to have /usr/bin/ld be a ld.lld
hardlink instead of /usr/bin/ld.bfd.
6. Request ports exp-runs and issue a call for testing with 3rd party
software. Fix issues found during this process.
7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using
architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld.

There is (some) support for mips and powerpc in lld, but I'm not sure
how well tested it is. RISC-V is not yet supported but there is a
desire to have a full LLVM-based RISC-V toolchain. I'm not aware of
any plan with respect to sparc64 in lld. In any case, I do not plan to
address these architectures in the initial lld work. In the near term
they will continue to use GNU ld 2.17.50.

I'm interested in your comments, questions and concerns about this plan.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Update on using LLVM's lld linker in the FreeBSD base system

2016-08-01 Thread Ed Maste
For some reason Warner's email didn't make it to me, but I spotted it
in the list archive.

Warner writes:
> On Mon, Aug 1, 2016 at 3:40 PM, Ed Maste  wrote:
>> -N/--omagic, used by some boot loader components. We can achieve the
>> same effect with a linker script.
>
> Agreed. Or objcopy even.

I'm not sure objcopy (alone) can do what we need, because -N also
turns off page alignment for .data. But either way I don't think will
be hard to work around.

>> 2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld
>> on the same architectures that use Clang (amd64, arm, arm64, i386). I
>> don't think there's a need for a WITH_LLD src.conf knob, but will add
>> one if desired.
>
> I'm on the fence here. Since it is ld.lld, I'm not sure there's much value
> here so long as it falls under one of the clang WITH/WITHOUT symbols.

Yeah, I planned to bundle it with some knob that already controls
lld's dependencies.

>> 4. Modify the boot loader and kernel builds to avoid using features
>> not implemented by lld.
>
> This can be done in parallel starting now. I may take a stab at the boot
> loader bits since I think that will be easy.

Sounds good. We want to have it done by that point in the list but
you're absolutely right that we don't need to wait to start working on
it. If it hasn't happened by the time we finish up the earlier tasks
I'll look at it then.

>> 6. Request ports exp-runs and issue a call for testing with 3rd party
>> software. Fix issues found during this process.
>
> Experience suggests this may be the long poll :)

Indeed, and that's a big part of my motivation for trying to make lld
more readily available as early as possible, even if we're still
waiting on some required features.

>> 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using
>> architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld.
>
> For the WITH/WITHOUT things, this is just a matter of changing the default
> MK_foo setting, right?

Right.

> OK. How does this square up against the gcc 4.2 removal timelines and
> plans? Once gcc is gone, we'll have to use an external toolchain anyway
> to build mips at least (though clang is close, it isn't there yet despite Sean
> Bruno's wonderful work).

I'm intentionally trying to keep lld decoupled from GCC 4.2 removal,
and don't think it should directly enable (or prevent) any progress
there. I don't yet have a good handle on GCC 4.2 removal timelines but
will definitely pay attention to progress there and potential
interaction with lld work.

> What's the timeline for all this stuff, do you think?

Significant progress is being made in lld at the moment. I don't want
to speak for others who are doing much of the work upstream, but I
would not be surprised if within two months we can build a working
world and kernel with lld (modulo rescue and boot loader fixes). If
testing and ports exp-runs go well I'd guess we could make it the
default in head a couple of months after that.

> Generally, I like it though. My concerns are mostly with ports and gcc plans.
> Though it isn't coupled to gcc, I'd suggest that we want to have a joint plan
> for both before we get out the axes. Note this is purely a timing argument,
> not whether to get them out, just when :)

Yes, fully agree. I want to have lld available as soon as is feasible,
but have no intention of trying to remove old GNU ld or GCC 4.2 until
a viable path forward exists for all architectures.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Time to enable partial relro

2016-08-26 Thread Ed Maste
On 26 August 2016 at 10:18, Warner Losh  wrote:
>
> So what's the summary of why we'd want to do that? What benefit does it bring?
> Sure, other folks do it, but why?

It's a relatively low cost technique to mitigate certain
vulnerabilities. rtld needs to write to some sections during load but
they don't need to be writeable after starting the program. relro
reorders the output sections so that they are grouped together, and
rtld remaps them read-only on start. This is often called "partial
relro." I don't know of any real downside to enabling it, other than
it could possibly break some strangely built third party software.
It's been enabled on other platforms for quite some time though and I
doubt we'd run into new issues.

It doesn't bring a huge benefit by itself though; the PLT is still
writeable. Adding "-z now" to the linker invocation produces "full
relro" which makes the PLT read-only too. It has a negative impact on
process start-up time though.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Update on using LLVM's lld linker in the FreeBSD base system

2016-09-07 Thread Ed Maste
On 1 August 2016 at 17:40, Ed Maste  wrote:
> Over the past year or so I have been investigating the state of LLVM's
> lld linker for use in the FreeBSD base system, to see if it could be
> used as FreeBSD's system linker.
>
> ...
> There are a few features used by the FreeBSD base system that lld
> developers (intentionally) do not expect to implement, unless they're
> reasonably widely used in a variety of different software. If they're
> not implemented we can modify FreeBSD to avoid using them. I'm aware
> of:
>
> -N/--omagic, used by some boot loader components. We can achieve the
> same effect with a linker script.

Warner addressed this for x86 boot components in r305353. We still
have an issue: lld does not support -Ttext, but does have an
-image-base option to set the start address. It would be nice to
reconcile this and LLVM PR 30269 is open to track this for lld.

> -dc, used by the rescue build. As long as object files are built
> specifically for rescue we can probably use -fno-common instead.

I briefly tried to get the rescue build working with lld, but was not
successful and have just left it disabled in my tests. We can
investigate this later.

> -b binary to convert binary files into ELF objects, used by some
> device drivers in kernel and module builds. We can use
> objcopy(elfcopy) instead.

There is now an lld change in progress to add support for -b binary:
https://reviews.llvm.org/D24060
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Retiring WITHOUT_ELFCOPY_AS_OBJCOPY option

2016-09-15 Thread Ed Maste
In FreeBSD 11 ELF Tool Chain's elfcopy is by default installed as
objcopy. The option to switch back to GNU objcopy is available by
setting WITHOUT_ELFCOPY_AS_OBJCOPY in make.conf.

As part of the plan to remove the outdated in-tree binutils in FreeBSD
12 I intend to remove the WITHOUT_ELFCOPY_AS_OBJCOPY build knob, after
FreeBSD 11.0 is released.

The patch is available in a Phabricator code review:
https://reviews.freebsd.org/D7337
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Update on using LLVM's lld linker in the FreeBSD base system

2016-09-27 Thread Ed Maste
On 1 August 2016 at 17:40, Ed Maste  wrote:
> Over the past year or so I have been investigating the state of LLVM's
> lld linker for use in the FreeBSD base system, to see if it could be
> used as FreeBSD's system linker.

A quick update: most of the required changes have now made it into
LLD, and I'm currently testing with an unmodified upstream LLD. I can
now build world and kernel with an out-of-tree LLD (setting XLD=...),
when using these src.conf knobs:

WITHOUT_BINUTILS
WITHOUT_BINUTILS_BOOTSTRAP
WITHOUT_BOOT
WITHOUT_RESCUE

There's some upstream work in progress that may address the the boot
issue, or at least part of it. Rescue will still be left for later.

LLD 3.9 will be available once dim@'s clang390-import branch is merged
to FreeBSD HEAD. Although it's a bit older than the LLD HEAD snapshot
I've been using for my testing, it will facilitate further testing and
experimentation with LLD (e.g. testing ports builds).
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: RPI3 - clang 3.9.0 issues

2016-10-17 Thread Ed Maste
On 17 October 2016 at 17:11, Shawn Webb  wrote:
>
> When the kernel is compiled with clang 3.9.0, it seems to freeze after
> being loaded by the clang 3.8 boot1.efi/loader.efi. I'm unsure if it's
> actually frozen or if simply nothing is being outputted to the console.
> Either way, I don't see console messages and the RPI3 _appears_ frozen.

This will probably be a bit tricky to track down. Have you tried
booting a Clang 3.8-compiled kernel with a Clang 3.9 boot1.efi and
loader.efi? Do you get any kernel output, or nothing after the last
lines of loader output?
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Update on using LLVM's lld linker in the FreeBSD base system

2016-11-25 Thread Ed Maste
LLD developers have made much progress since my last update in August.

Two options used by the FreeBSD build, -dc and -r, are now
implemented. The issues with linker script expression support and
symbol version maps have been addressed. At this point an LLD built
from subversion can link a working FreeBSD-HEAD kernel and world
except for the boot loaders.

Here's an update on the plan I posted previously:

> 1. Update lld along with the Clang/LLVM 3.9 update that dim@ is working on.
> 2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld
> on the same architectures that use Clang (amd64, arm, arm64, i386). I
> don't think there's a need for a WITH_LLD src.conf knob, but will add
> one if desired.

Now complete, with Dimitry's import of Clang 3.9.0 in r309124. There
is a WITH_/WITHOUT_LLD knob, which defaults to on for amd64 and arm64,
and off for all other architectures for now.

> 3. Update lld again (most likely to a snapshot from upstream SVN) once
> it is able to link an unmodified FreeBSD kernel.

This is now possible, but I'm going to wait for 3.9.0 to settle and
for the 3.9.1 update to happen first.

> 4. Modify the boot loader and kernel builds to avoid using features
> not implemented by lld.

There are a few outstanding issues in LLD that prevent linking the
boot loaders, but I'm hopeful that they will be addressed in the near
future.

> 5. Introduce a WITH_LLD_AS_LD knob to have /usr/bin/ld be a ld.lld
> hardlink instead of /usr/bin/ld.bfd.

I've added this already, to allow for testing and experimentation, and
to provide some linker on arm64 image builds that can be used to
bootstrap a later GNU ld or LLVM lld. It defaults to on for arm64 and
off everywhere else. Note that the knob affects the installed linker
(/usr/bin/ld), but does not change the linker actually used to build
world and kernel, which remains GNU ld.

> 6. Request ports exp-runs and issue a call for testing with 3rd party
> software. Fix issues found during this process.

This can start happening any time now for LLD 3.9.0, either by setting
WITH_LLD_AS_LD with poudriere, or by using -fuse-ld=lld in LDFLAGS.

For example,
% cd /usr/src/bin/ls
% LDFLAGS=-fuse-ld=lld make

> 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using
> architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld.

It's still too early to plan a switch by default.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: WITH_LLVM_LIBUNWIND vs. WITHOUT_LLVM_LIBUNWIND, clang vs. gcc (such as devel/powerpc64-xtoolchain-gcc ): What is intended to be required for C++ exceptions to work?

2016-11-29 Thread Ed Maste
On 29 November 2016 at 16:46, Mark Millard  wrote:
>
>
> Summary: Does using clang 3.9.0 as the system compiler imply one should or
> must (eventually?) use WITH_LLVM_LIBUNWIND to have C++ exceptions work?
>
> Do WITH_LLVM_LIBUNWIND and WITHOUT_LLVM_LIBUNWIND have the same criteria
> for what dwarfdump should show for the exception information (if the
> information to be shown is to be correct/sufficient for libunwind)?

It does not. It should be possible to build a functional system both
WITH_ and WITHOUT_LLVM_LIBUNWIND. The compiler is unaware of the
_LLVM_LIBUNWIND setting. Both unwind libraries use the same unwind
data.

Eventually new features may show up in Clang and LLVM's libunwind (and
new versions of GNU's unwinder) that won't work with the old unwinder.

> Your answer's detail might indicate that I've misdirected the llvm folks
> in submittals like  https://llvm.org/bugs/show_bug.cgi?id=26844 .
>
> There is also the question of if/when llvm's libunwind is ready to be used
> for powerpc64 or powerpc (or . . .) if there are architecture specifics
> involved. That answer might determine when C++ exceptions work (and so
> when devel/kyua might have a chance to work) and is sort of separate from
> the main question here but is still of interest overall.
>
> Should powerpc64 and powerpc clang 3.9.0 testing be using
> WITH_LLVM_LIBUNWIND ? WITHOUT_LLVM_LIBUNWIND ? Both?

For testing I think WITH_LLVM_LIBUNWIND is the interesting case. My
eventual goal is to have a functioning Clang, LLD, LLDB, libunwind,
and ELF Tool Chain on all of our supported architectures.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: I've submitted llvm bugzilla report 31538 on clang 3.9.1 not supporting the mfpmr and mtpmr instructions used in dev/hwpmc/hwpmc_e500.c

2017-01-05 Thread Ed Maste
On 4 January 2017 at 17:46, Mark Millard  wrote:
> I have submitted to llvm (matching up with FreeBSD bugzilla 214904):
>
> Bug 31538 - FreeBSD head (12) buildkernel based on clang FreeBSD's 3.9.1 
> stops for mfpmr and mtpmr instructions not being supported (used in 
> dev/hwpmc/hwpmc_e500.c )

Thank you.

> This report likely should be added to the depends on list in:
>
> Bug 25780 - [META] Using Clang as the FreeBSD/ppc system compiler

Agreed, I've added it there. Please feel free to add other issues you
find as blocking 25780; my intent is to have it track all of the
outstanding issues preventing a Clang-based "make buildworld
buildkernel" from succeeding on any ppc / ppc64.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374

2017-01-11 Thread Ed Maste
On 11 January 2017 at 04:15, Mark Millard  wrote:
>
> # ./a.out
> ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374
> Abort trap (core dumped)

Would you paste the output of `readelf -r a.out`?
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: clang on armv6 incorrectly emits call to sincos()

2017-01-11 Thread Ed Maste
On 11 January 2017 at 09:42, Jia-Shiun Li  wrote:
>
> Think this optimization should be turned off for armv6 from base
> clang/llvm, instead of patching individual ports or ports infrastructure.

You're right that this needs to be fixed in the compiler or the base
system, not individual ports. LLVM has a hasSinCos() and should not be
emitting the sincos libcall on platforms that do not have it. Would
you care to submit a PR for this?

-Ed
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374

2017-01-11 Thread Ed Maste
On 11 January 2017 at 21:06, Roman Divacky  wrote:
> Looks like a progress :) Three questions...
>
> Is the readelf -a reasonable now?

FYI, I just committed an ELF Tool Chain fix (r311941) so readelf
should display the relocation types properly now.

> If you compile with -g, does the
> backtrace make a bit more sense? And finally, can you try to "nexti/stepi" in 
> gdb from
> _start to see where things go wrong? Possibly doing it both for ld linked 
> a.out
> and lld linked a.out and compare where things differ.

You can also build rtld with additional debugging by adding -DDEBUG to
CFLAGS. In libexec/rtld-elf/Makefile there's an example command line
for building it locally, but I've just added CFLAGS+=-DDEBUG to the
Makefile in my test tree and built it along with the rest of my full
cross build.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: elfdump doesn't support .a files?

2017-01-19 Thread Ed Maste
On 17 January 2017 at 18:06, Ngie Cooper (yaneurabeya)
 wrote:
> Hi Ed,
> I tried running elfdump on a .a archive and it seems that elfdump 
> doesn’t support this (whereas objdump does). Is this expected?

Indeed it does not. We're still using FreeBSD's original elfdump. The
ELF Tool Chain project (which provides the objcopy, size, strings etc.
that we use) also imported FreeBSD's elfdump and made some
enhancements, including the ability to handle .a files.

Unfortunately there are a few changes which exist in FreeBSD's elfdump
but not ELF Tool Chain's version. We need to port those from FreeBSD
to ELF Tool Chain before we can migrate to ELF Tool Chain's elfdump.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: clang 4.0.0 with_lld_is_ld build

2017-02-07 Thread Ed Maste
On 7 February 2017 at 17:32, Shawn Webb  wrote:
> Hey All,
>
> On a system with clang 4.0.0 already installed with lld as ld, I get the
> following error compiling the latest HEAD of projects/clang400-import when
> WITH_LLD_IS_LD is set:

For now try setting WITHOUT_SYSTEM_COMPILER.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: clang 4.0.0 with_lld_is_ld build

2017-02-08 Thread Ed Maste
On 8 February 2017 at 08:10, Shawn Webb  wrote:
> On Tuesday, 07 February 2017 06:55:44 PM Ed Maste wrote:
>> On 7 February 2017 at 17:32, Shawn Webb  wrote:
>> > Hey All,
>> >
>> > On a system with clang 4.0.0 already installed with lld as ld, I get the
>> > following error compiling the latest HEAD of projects/clang400-import when
>>
>> > WITH_LLD_IS_LD is set:
>> For now try setting WITHOUT_SYSTEM_COMPILER.
>
> buildworld now works when also setting WITHOUT_SYSTEM_COMPILER.

Thanks for the report and testing.

I've created https://reviews.freebsd.org/D9487 to set this
automatically for now, and later we'll need to add a FreeBSD-specific
version to the linker (or just share Clang's FREEBSD_CC_VERSION) and
compare the host / in-tree linker versions as well.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: /tmp/ecp.* created during kernel build?

2017-03-30 Thread Ed Maste
[redirected to freebsd-toolchain]

On 24 March 2017 at 08:21, Andre Albsmeier  wrote:
>
> Interesting is also that libc.a grows(!):
>
> Before the strip:
> -r--r-  1 andre  wheel  2622684 24 Mar 13:18 libc.a
>
> After:
> -r--r-  1 andre  wheel  2713792 24 Mar 13:19 libc.a

It seems this is a side effect of the way elfcopy writes the new
archive and objects.

Using diffoscope to compare libc.a and a stripped libc.a we see a few
interesting things:
% objcopy --strip-debug /usr/lib/libc.a libc.strip1.a
% diffoscope /usr/lib/libc.a libc.strip1.a
--- /usr/lib/libc.a
+++ libc.strip1.a
├── file list
│ @@ -1,1258 +1,1258 @@
│ ---   00083210 1970-01-01 00:00:00.00 /
│ +--   00083210 2017-03-30 19:01:14.00 /

* Elfcopy is updating the timestamp on the "/" entry, despite leaving
all other archive metadata alone.

│ --rw-r--r--   000 1104 1970-01-01
00:00:00.00 iconvlist.o
│ +-rw-r--r--   000 1184 1970-01-01
00:00:00.00 iconvlist.o

* As you discovered output is larger, and this is true for the
individual .o files in the .a archive.

│  File: lib.a(iconvctl.o)
│  ELF Header:
│Magic:   7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00
│Class: ELF64
│Data:  2's complement, little endian
│Version:   1 (current)
│OS/ABI:FreeBSD
│ABI Version:   0
│Type:  REL (Relocatable file)
│Machine:   Advanced Micro Devices x86-64
│Version:   0x1
│Entry point address:   0
│Start of program headers:  0 (bytes into file)
│ -  Start of section headers:  528 (bytes into file)
│ +  Start of section headers:  536 (bytes into file)
│Flags: 0
│Size of this header:   64 (bytes)
│Size of program headers:   0 (bytes)
│Number of program headers: 0
│Size of section headers:   64 (bytes)
│ -  Number of section headers: 9
│ -  Section header string table index: 1
│ +  Number of section headers: 10
│ +  Section header string table index: 9

Section headers are at a different offset, elfcopy/strip output has an
extra section.

├── readelf --wide --sections {}
│ @@ -1,23384 +1,24634 @@
│
│  File: lib.a(iconvlist.o)
│ -There are 9 section headers, starting at offset 0x210:
│ +There are 10 section headers, starting at offset 0x220:
│
│  Section Headers:
│[Nr] Name  TypeAddr Off
Size   ES Flg Lk Inf Al
│[ 0]   NULL 00
00 00  0   0  0
│ -  [ 1] .strtab   STRTAB   000180
8c 00  0   0  1
│ -  [ 2] .text PROGBITS 40
0a 00  AX  0   0 16
│ -  [ 3] .rela.textRELA 000150
18 18  8   2  8
│ -  [ 4] .comment  PROGBITS 4a
53 01  MS  0   0  1
│ -  [ 5] .note.GNU-stack   PROGBITS 9d
00 00  0   0  1
│ -  [ 6] .eh_frame X86_64_UNWIND    a0
38 00   A  0   0  8
│ -  [ 7] .rela.eh_frameRELA 000168
18 18  8   6  8
│ -  [ 8] .symtab   SYMTAB   d8
78 18  1   3  8
│ +  [ 1] .text PROGBITS 40
0a 00  AX  0   0 16
│ +  [ 2] .rela.textRELA 000180
18 18   I  7   1  8
│ +  [ 3] .comment  PROGBITS 4a
53 01  MS  0   0  1
│ +  [ 4] .note.GNU-stack   PROGBITS 9d
00 00  0   0  1
│ +  [ 5] .eh_frame X86_64_UNWIND    a0
38 00   A  0   0  8
│ +  [ 6] .rela.eh_frameRELA 000198
18 18   I  7   5  8
│ +  [ 7] .symtab   SYMTAB   d8
a8 18  8   5  8
│ +  [ 8] .strtab   STRTAB   0001b0
1b 00  0   0  1
│ +  [ 9] .shstrtab STRTAB   0001cb
4e 00  0   0  1
│  Key to Flags:
│W (write), A (alloc), X (execute), M (merge), S (strings)
│I (info), L (link order), G (group), x (unknown)
│O (extra OS processing required) o (OS specific), p (processor specific)

Sections are in a different order, and elfcopy/strip includes a
separate section header string table, while Clang's output stores both
symbol names and names used in the section header in .strtab. The
increased size is interesting and somewhat unfortunate, but not
necessarily a bug.

> strip (objcopy) does more curious things:
>
> $ cd /tmp
> $ cp /usr/lib/libc.a .
> $ strip --strip-debug libc.

April 2017 update on using LLVM's lld linker in the FreeBSD base system

2017-04-05 Thread Ed Maste
Here's a fresh update on LLVM's LLD linker in the base system,
referencing the plan originally posted at the beginning of 2016. This
work is primarily taking place on amd64 right now, and unless
otherwise noted these results apply to amd64.

First, the completed items:

> 1. Update lld along with the Clang/LLVM 3.9 update that dim@ is working on.
> 2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld
> on the same architectures that use Clang (amd64, arm, arm64, i386).
> 3. Update lld again (most likely to a snapshot from upstream SVN) once
> it is able to link an unmodified FreeBSD kernel.

We now have LLD 4.0.0 in the tree and it can build all of
FreeBSD/amd64 kernel and world, and most of ports.

> 4. Modify the boot loader and kernel builds to avoid using features
> not implemented by lld.
> 5. Introduce a WITH_LLD_AS_LD knob to have /usr/bin/ld be a ld.lld
> hardlink instead of /usr/bin/ld.bfd.

This became WITH_LLD_IS_LD for consistency with WITH_CLANG_IS_CC. It
also controls the bootstrap linker: adding WITH_LLD_IS_LD=yes to
src.conf means that the system will be built with LLD, and LLD will be
/usr/bin/ld in the resulting world.

This option is currently enabled by default on arm64 (only).


Next, where we are today:

> 6. Request ports exp-runs and issue a call for testing with 3rd party
> software. Fix issues found during this process.

This is in progress now, in PR 214864. There are currently 270 failing
ports and 963 skipped. The top ten failing ports (by # skipped) are
responsible for 808 of the skipped; addressing those should allow us
to build nearly 98% of the ports collection with LLD.

For reference, the top ten ports by # skipped are: audio/openal-soft
devel/libunwind editors/libreoffice lang/fpc print/gl2ps editors/emacs
lang/gcc6-aux lang/mono archivers/arj multimedia/libxine


Finally, future tasks:

> 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using
> architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld.

While there is still no timeline set for this, it is already done for
arm64 (where we have no in-tree GNU ld available), and it is close to
being feasible for amd64. Further investigation is needed on i386 and
32-bit arm before moving forward here.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: April 2017 update on using LLVM's lld linker in the FreeBSD base system

2017-04-05 Thread Ed Maste
On 5 April 2017 at 16:09, Dimitry Andric  wrote:
>
> Note that as of r316432, all of the above is also available in the
> stable/11 branch.

However some of the changes to FreeBSD haven't yet been merged to
stable/11, and it's probably not possible to build world + kernel with
LLD (via WITH_LLD_IS_LD) on stable/11 today. I expect these to be
merged over time, but this is still very much an experimental feature
right now.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: FYI: amd64 built with WITH_LLD_IS_LD= vs. devel/libunwind : cannot preempt symbol (for various symbols)

2017-04-16 Thread Ed Maste
On 16 April 2017 at 04:10, Mark Millard  wrote:
> Context: amd64 FreeBSD -r316952 as a VirtualBox guest
> that was built using WITH_LLD_IS_LD= . ports -r438577.
>
> x11/xorg-minimal indirectly gets to devel/libunwind and
> devel/libunwind fails to build from source:
>
>
> --- Lperf-simple ---
> libtool: link: cc -O2 -pipe -g -fstack-protector -fno-strict-aliasing 
> -fexceptions -Wall -Wsign-compare -fstack-protector -o .libs/Lperf-simple 
> Lperf-simple.o  ../src/.libs/libunwind.so -lgcc -llzma -Wl,-rpath 
> -Wl,/usr/local/lib
> /usr/bin/ld: error: ./Gperf-simple.c:195: cannot preempt symbol 
> '_ULx86_64_init_local' defined in ../src/.libs/libunwind.so

The LLD ports exp-run identified the "cannot preempt symbol" issue as
being responsible for the largest number of failed or skipped ports.
You can find a description of the issue in LLVM PR 30960
(https://bugs.llvm.org//show_bug.cgi?id=30960). This is a tricky
issue, and one for which there's not a clear right answer, but is
arguably a problem that needs to be addressed in the individual pieces
of software (libunwind, openal-soft, etc.)

As a temporary workaround you can add CFLAGS+= -fPIC to the port's
Makefile, as in
https://github.com/emaste/freebsd-ports/commit/4857444b31ca546e29e221dce2a41092765e6062
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: WITH_LLD_IS_LD vs default WITHOUT_SYSTEM_COMPILER: What are the reasons?

2017-04-17 Thread Ed Maste
On 14 April 2017 at 20:16, Mark Millard  wrote:
> So it sounds like I can freely mix WITH_LLD_IS_LD and WITH_SYSTEM_COMPILER
> in any system-clang 4.0 based system build context, no actual problem
> cases, even if the existing system build used a binutils ld (for example).

Yes. WITH_LLD_IS_LD implying WITHOUT_SYSTEM_COMPILER was added because
LLD requires tblgen and libllvm, but they were originally built only
when needed for Clang. In cases where the SYSTEM_COMPILER default
logic determined that the host compiler was identical to the
to-be-built bootstrap compiler the build would skip building Clang,
tblgen, and libllvm. This was fixed by r316647 and the connection
between LLD_IS_LD and SYSTEM_COMPILER can be removed in due course.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: svn commit: r317159 - head/contrib/libstdc++/config/abi/pre

2017-04-19 Thread Ed Maste
On 19 April 2017 at 15:06, Ed Maste  wrote:
> Author: emaste
> Date: Wed Apr 19 19:06:47 2017
> New Revision: 317159
> URL: https://svnweb.freebsd.org/changeset/base/317159
>
> Log:
>   libstdc++: fix symbol version script for LLD
>
>   LLD is less tolerant of inconsistencies in the symbol version script.
>
>   - Add a ; on the last entry in a version block
>   - Remove duplicated symbols, retaining those in the earliest block

For reference, with this change and two others I was able to link
FreeBSD/mips64 world and kernel using the in-tree LLD 4.0.0, although
I haven't yet tested the result. Everything was compiled with the
in-tree GCC 4.2.1.

The other changes I used:
1) applying -mxgot globally, by adding it to CFLAGS in bsd.cpu.mk
2) disabling static_libpam in lib/libpam/Makefile

There is a patch in LLVM's Phabricator to add multi-GOT support to
LLD[1], although it's meeting some resistance: LLD's main authors
don't want the additional complexity in LLD to support ABI oddities
that only apply to MIPS.

The static libpam failed because it needs to output a relocatable
object (ld -r) from multiple input object objects with
different/non-zero ri_gp_value, and LLD is not capable of this.

[1] https://reviews.llvm.org/D31528
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


June 2017 update on using LLVM's lld linker in the FreeBSD base system

2017-06-12 Thread Ed Maste
Another update on using LLD as the FreeBSD base system linker:

> We now have LLD 4.0.0 in the tree and it can build all of
> FreeBSD/amd64 kernel and world, and most of ports.

LLD 4.0.0 is in HEAD and stable/11, and WITH_LLD_IS_LD and
WITH_LLD_BOOTSTRAP are enabled by default for arm64 on both branches.
There are a few post-4.0.0 bugfixes in LLD that we need to import into
HEAD in short order and MFC for the 11.1 release.

It is possible to build both the amd64 and arm64 world + kernel with
WITH_LLD_IS_LLD and WITH_LLD_BOOTSTRAP. My daily driver desktop and
laptop are using LLD as /usr/bin/ld.

>> 6. Request ports exp-runs and issue a call for testing with 3rd party
>> software. Fix issues found during this process.
>
> This is in progress now, in PR 214864. There are currently 270 failing
> ports and 963 skipped. The top ten failing ports (by # skipped) are
> responsible for 808 of the skipped; addressing those should allow us
> to build nearly 98% of the ports collection with LLD.

bapt@ and I discussed this at BSDCan and we intend to create a way to
flag ports that don't build with LLD. Then the ports infrastructure
can automatically use ld.bfd, until the issue is addressed in the
individual port or in LLD. It will be something like
"USES=linker:not_lld" or "LLD_UNSAFE=yes" or so.

>> 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using
>> architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld.
>
> While there is still no timeline set for this, it is already done for
> arm64 (where we have no in-tree GNU ld available), and it is close to
> being feasible for amd64. Further investigation is needed on i386 and
> 32-bit arm before moving forward here.

Once the ports infrastructure is in place I plan to enable LLD as
/usr/bin/ld by default on amd64.

Outstanding issues with i386 and 32-bit arm prevent us from turning it
on for those architectures right now. The LLVM tracking bug in
http://llvm.org/pr23214 depends on those individual issues; i386
should be relatively straightforward, while arm needs more work.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: June 2017 update on using LLVM's lld linker in the FreeBSD base system

2017-07-04 Thread Ed Maste
On 12 June 2017 at 17:21, Ed Maste  wrote:
> Another update on using LLD as the FreeBSD base system linker:

Since "amd64" and "arm64" look similar, let me clarify one point:

arm64 -- 64-bit ARM -- is built with, and has as /usr/bin/ld, LLD
4.0.0. This is true in HEAD and in stable/11 (and hence the upcoming
11.1)

amd64 -- 64-bit x86 -- is built with, and has as /usr/bin/ld, GNU BFD
ld 2.17.50. LLD is installed as ld.lld; adding -fuse-ld=lld to CFLAGS
can be used to test linking various software with LLD. Also, the amd64
linker will not change in stable/11.

> Then the ports infrastructure
> can automatically use ld.bfd, until the issue is addressed in the
> individual port or in LLD. It will be something like
> "USES=linker:not_lld" or "LLD_UNSAFE=yes" or so.

Still waiting on this; once it is ready I expect to switch amd64 to LLD.

> Outstanding issues with i386 and 32-bit arm prevent us from turning it
> on for those architectures right now. The LLVM tracking bug in
> http://llvm.org/pr23214 depends on those individual issues; i386
> should be relatively straightforward, while arm needs more work.

i386 still needs investigation, but progress has been made on 32-bit
arm. andrew@ booted an lld-linked arm kernel/userland to the login
prompt, with a few workarounds. Note that this is specifically for
armv7. LLD does not currently support earlier ARM architectures.
TARGET_ARCH=armv7 support is in discussion/planning, and for now I
assume that we'd initially switch only it to LLD. TARGET_ARCH=arm and
TARGET_ARCH=armv6 will continue to use ld.bfd.

It appears we are on a credible path to enable LLD by default in 12.0
for the tier-1 and almost tier-1 architectures of i386, amd64, armv7,
arm64.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: svn commit: r322824 - in head: lib/clang share/mk usr.bin/clang

2017-08-25 Thread Ed Maste
On 25 August 2017 at 14:07, Ryan Libby  wrote:
> On Wed, Aug 23, 2017 at 4:30 PM, John Baldwin  wrote:
>> Author: jhb
>> Date: Wed Aug 23 23:30:25 2017
>> New Revision: 322824
>> URL: https://svnweb.freebsd.org/changeset/base/322824
>>
>> Log:
>>   Improve the coverage of debug symbols for MK_DEBUG_FILES.
>>
...
> This causes llvm to emit hundreds of new warnings [1] for
> "DWARF2 only supports one section per compilation unit"
>
> Are these expected?  Are they a concern?  Should we silence them?
> Is this an upstream llvm bug [2]?

I'm not sure they were "expected" but I guess are an unsurprising
consequence of building more things with debug. In any case they're
not a concern.

It is an llvm bug (the warning really ought not be emitted for empty
sections), but upstream is probably not too concerned as (most? all)
other platforms are not using dwarf2.

The right answer for us is likely to just stop defaulting to dwarf2
(and specifying it via CFLAGS for kernel if necessary).
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: svn commit: r325320 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs [breaks lld on zfs: lld uses fallocate]

2017-11-04 Thread Ed Maste
On 4 November 2017 at 07:41, Andriy Gapon  wrote:
> On 04/11/2017 12:32, Mark Millard wrote:
>>   if (int Err = ::posix_fallocate(FD, 0, Size)) {
>> if (Err != EOPNOTSUPP)
>>   return std::error_code(Err, std::generic_category());
>>   }
>
> The commit message that you didn't include into your reply contains some 
> useful
> information that authors / maintainers of this code should probably take into
> account:
>
>>   Please note that EINVAL is used to report that the underlying file system
>>   does not support the operation (POSIX.1-2008).
>
> Here is a link for that:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_fallocate.html

I have no idea how they decided EINVAL was a reasonable errno for this case.

Mark, can you give this patch a try:

diff --git a/contrib/llvm/lib/Support/Unix/Path.inc
b/contrib/llvm/lib/Support/Unix/Path.inc
index 45097eb918b7..67edb46f0025 100644
--- a/contrib/llvm/lib/Support/Unix/Path.inc
+++ b/contrib/llvm/lib/Support/Unix/Path.inc
@@ -427,7 +427,7 @@ std::error_code resize_file(int FD, uint64_t Size) {
   // If we have posix_fallocate use it. Unlike ftruncate it always allocates
   // space, so we get an error if the disk is full.
   if (int Err = ::posix_fallocate(FD, 0, Size)) {
-if (Err != EOPNOTSUPP)
+if (Err != EINVAL && Err != EOPNOTSUPP)
   return std::error_code(Err, std::generic_category());
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Ports and LLVM's lld linker

2017-12-18 Thread Ed Maste
On 27 November 2017 at 15:39, Ed Maste  wrote:
> We're making good progress on using LLVM's lld linker as FreeBSD's
> /usr/bin/ld, so I'd like to raise awareness of the new linker within
> the ports community.

With a couple of recent changes in src head (r326831 and r326897) lld
is now suitable for use as the base system /usr/bin/ld on amd64 and
i386. We're working through ports failures, starting with those
responsible for the largest number of skipped ports.

The top four, on amd64:

port# skipped
devel/libunwind 7994
databases/postgresql*-client230
lang/fpc76
lang/mono   22

The remaining failures are responsible for no more than 2 skipped ports each.

devel/libunwind fails due to the shared object protected visibility
symbol preemption issue; Dimitry Andric and I are searching for an
appropriate fix.

The databases/postgresql*-client failures have been worked around by
r456635, adding LLD_UNSAFE=yes so that the port uses ld.bfd.

lang/fpc appears to suffer from stricter validation performed by lld:
/usr/bin/ld: error: x86_64/units/x86_64-freebsd/i_linux.o: invalid
alignment of section headers

lang/mono fails because lld defaults to -z text, disallowing
relocations in read-only segments (like .text). A workaround is to add
-z notext to the link command line, which turns off lld's error for
this case and results in the same behaviour as ld.bfd and ld.gold
provide by default.

Unfortunately usual workarounds (LLD_UNSAFE=yes or
LDFLAGS=Wl,-z,notext) fail for both lang/fpc and lang/mono, and it's
not immediately obvious to me how their respective builds handle the
options. I'll probably need help from acm@ and mono@ for these.

For reference the remaining ports failing with lld on amd64 are:
archivers/lua51-zlib
audio/alure
benchmarks/wrk
databases/postgres-xl
devel/libds
devel/libtecla
devel/pdcurses
devel/ztcl
emulators/gem5
ftp/rexx-curl
irc/eggdrop
irc/eggdrop-devel
irc/evangeline
lang/rexx-imc
lang/rexx-regutil
lang/siod
lang/smlnj
lang/tclX
mail/qmail-dk
math/rexx-regmath
misc/seabios
net-im/uTox
net/py-netif
net/py-netif
print/openprinting
print/pdftk
security/otpw
shells/bash-static
sysutils/dupd
sysutils/e2fsprogs
sysutils/installwatch
sysutils/unieject
www/cgihtml
www/dummyflash
www/mod_jk
www/mozplugger
www/tdom
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Ports and LLVM's lld linker

2017-12-22 Thread Ed Maste
On 18 December 2017 at 22:10, Ed Maste  wrote:
>
> With a couple of recent changes in src head (r326831 and r326897) lld
> is now suitable for use as the base system /usr/bin/ld on amd64 and
> i386. We're working through ports failures, starting with those
> responsible for the largest number of skipped ports.
>
> The top four, on amd64:
>
> port# skipped
> devel/libunwind 7994
> databases/postgresql*-client230

These two are now addressed by setting LLD_UNSAFE=yes so that they'll
still link with ld.bfd once ld.lld is installed as /usr/bin/ld.

The issue with libunwind was already reported upstream (from someone
trying to use ld.gold, which fails in the same way), and libunwind's
developers will address it in a new version.

The postgresql*-client issues need more investigation, but now will
not prevent the migration to lld.

> lang/fpc76

This one's a little tricky, because it's a (Pascal) tool chain that
doesn't support usual environment variables like LD to specify a
linker explicitly.

> lang/mono   22

I'll mark this one LLD_UNSAFE after a libtool dependency is sorted out
(PR224514).

After setting LLD_UNSAFE=yes for libunwind some previously-skipped
ports attempt to build, and some of those now fail with lld. I'm
working through that list and may have a dozen or so more that will
become LLD_UNSAFE.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Migrating arm(v7) to LLD_BOOTSTRAP

2018-01-16 Thread Ed Maste
With the update to Clang/LLVM/lld 6.0.0 I believe lld is nearly ready
to be used as the system linker for armv7, and I plan to enable
LLD_BOOTSTRAP by default after a couple of WIP patches land and after
a little more testing. This may happen a week or two from now. This
should have little impact on port builds, because /usr/bin/ld will
still be GNU ld.bfd (although there may be some unexpected fallout).

I expect to enable LLD_IS_LD by default a little later, and
/usr/bin/ld will then be lld. This is the same path we're taking with
amd64.

lld currently does not support architectures prior to armv7, and fails
with some combination of these errors when I try to use it for
arm{,v5,v6,eb}:

ld: error: lld uses blx instruction, no object with architecture
supporting feature detected.
ld: error: lld uses extended branch encoding, no object with
architecture supporting feature detected.
ld: error: lld may use movt/movw, no object with architecture
supporting feature detected.

I expect this will be addressed in a future version of lld.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Migrating arm(v7) to LLD_BOOTSTRAP

2018-03-15 Thread Ed Maste
On 17 January 2018 at 00:35, Michal Meloun  wrote:
>
>>> ld: error: lld may use movt/movw, no object with architecture
>>> supporting feature detected.
>
> But this means that we can not use lld for kernel module linking.
> (assuming that lld can emits movt/movw with attached relocation).

Right now for pre-v7 lld exits with the "may use" before attempting to
link, with no indication of whether movt/movw would actually be used.

It seems in practice linking armv7 with lld does not use movt/movw.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Heads-up: linker (lld) changes for amd64 coming soon

2018-03-26 Thread Ed Maste
Some changes related to the amd64 linker are nearly ready to be
committed (within a week or three), so I'm sending this notice to
request any final comments or concerns before these changes are made.

1. Kostik (kib@) has a patch to start using kernel ifunc, with the
first use being Supervisor Mode Access Prevention (SMAP) on amd64.
This relies on linker support that is available in the in-tree lld and
in contemporary binutils ld.bfd from ports, but not in the in-tree
ld.bfd 2.17.50.

Right now we use lld as the default bootstrap linker for amd64 in
-CURRENT -- that is, the kernel, and userland libraries and binaries
are linked with lld. To revert to ld.bfd for amd64 the build-time knob
WITHOUT_LLD_BOOTSTRAP=yes can currently be added to src.conf. When the
ifunc changes get committed WITHOUT_LLD_BOOTSTRAP=yes will not work
for amd64 kernels (and will be added to BROKEN_OPTIONS).

2. WITH_LLD_IS_LD controls whether /usr/bin/ld is ld.bfd or ld.lld,
and thus the linker used for linking ports. I plan to switch this to
default on.

Most ports build just fine when lld is the system linker, but a few
encounter trouble: some of the ports rely on options not supported by
lld, rely on specific quirks of ld.bfd's implementation, or have a
buggy linker invocation that is silently ignored by ld.bfd.

The majority of such ports have now been adapted to work with lld or
configured to use ld.bfd as the linker, but there are a small number
of failing ports that do not provide a way to use other than the
default system linker /usr/bin/ld. The outstanding issues can be found
in the ports exp-run for lld as /usr/bin/ld, PR214864.

Please follow up if you have any concerns or comments about these
upcoming changes.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Heads-up: linker (lld) changes for amd64 coming soon

2018-03-27 Thread Ed Maste
On 27 March 2018 at 02:20, Antoine Brodin  wrote:
>> 1. Kostik (kib@) has a patch to start using kernel ifunc, with the
>> first use being Supervisor Mode Access Prevention (SMAP) on amd64.
>> This relies on linker support that is available in the in-tree lld and
>> in contemporary binutils ld.bfd from ports, but not in the in-tree
>> ld.bfd 2.17.50.
>
> I have no concerns about 1.

OK. My guess is I won't get any other feedback on this one until it
makes it into a release. I suspect kib will commit this part later
this week or early next week.

>> 2. WITH_LLD_IS_LD controls whether /usr/bin/ld is ld.bfd or ld.lld,
>> and thus the linker used for linking ports. I plan to switch this to
>> default on.
>>
>
> About 2.,  I am concerned that changes breaking a large number of
> ports are committed without portmgr@ approval.
> If WITH_LLD_IS_LD is committed as is on amd64,  packages for head
> won't be published as it doesn't meet our current criteria for
> publication.

Fair enough - this was the reason I sent the email. I've now gone
through and submitted a PR for for each failure that did not already
have one. I've also added LLD_UNSAFE to a few ports where where it was
straightforward.

In this batch of PRs I noticed four main issues:

1. Ports that pass compiler flags, such as -fPIC, to the linker. lld
has more strict command-line parsing and rejects these invalid
invocations, while ld.bfd happily creates bogus output (e.g. a shared
library with a DT_AUXILIARY entry of "PIC"). PR 221808 has a
reasonable discussion of this issue.

2. lld has no built-in search paths (/lib, /usr/lib). Normally the
linker is invoked from the compiler driver, which provides default
search paths. If lld is invoked directly then library search paths
must be specified explicitly with -L/lib -L/usr/lib.

3. Shared library protected visibility symbol preemption.

4. lld does not have a built-in default output target. For the common
use of the linker (linking individual .o objects into an executable or
shared object) lld infers the target from the first object file.
However, when the linker is used to convert an arbitrary binary file
into an ELF ojbect (via -r -b binary) lld needs the output target to
be specified explicitly with -m.

The vast majority of skipped ports in the exp-run come from two
failures: lang/ghc (PR226872) and lang/fpc (222172). The PR for
lang/ghc reports that the current released version of ghc mentions
improved lld support; I hope the port update will solve this issue.

I submitted a bug report upstream for lang/fpc about one fpc bug that
affected lld, and that issue has now been resolved upstream. We'll
need to check again once the port is updated.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Heads-up: linker (lld) changes for amd64 coming soon

2018-03-27 Thread Ed Maste
(Moved from -current to -ports)

On 27 March 2018 at 13:15, Ed Maste  wrote:
>
> Fair enough - this was the reason I sent the email. I've now gone
> through and submitted a PR for for each failure that did not already
> have one. I've also added LLD_UNSAFE to a few ports where where it was
> straightforward.

Via tobik's commit to lang/myrddin (r465725) I discovered
BINARY_ALIAS=ld=ld.bfd, which is a usable workaround for some ports
which don't honour $LD or -fuse-ld=bfd in CFLAGS.

As you point out in reply to my r465755 BINARY_ALIAS alone is not
sufficient, because arm64 does not provide ld.bfd by default and
LLD_UNSAFE automatically brings in ports binutils if /usr/bin/ld.bfd
does not exist. So we need both LLD_UNSAFE and BINARY_ALIAS.

Should we just have LLD_UNSAFE also set BINARY_ALIAS=ld=ld.bfd?
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Heads-up: linker (lld) changes for amd64 coming soon

2018-03-29 Thread Ed Maste
On 27 March 2018 at 18:21, Ed Maste  wrote:
> (Moved from -current to -ports)
>
> On 27 March 2018 at 13:15, Ed Maste  wrote:
>>
>> Fair enough - this was the reason I sent the email. I've now gone
>> through and submitted a PR for for each failure that did not already
>> have one. I've also added LLD_UNSAFE to a few ports where where it was
>> straightforward.
>
> Via tobik's commit to lang/myrddin (r465725) I discovered
> BINARY_ALIAS=ld=ld.bfd, which is a usable workaround for some ports
> which don't honour $LD or -fuse-ld=bfd in CFLAGS.

As of ports r465900 BINARY_ALIAS is now set automatically if LLD_UNSAFE is set.

There are now 14 PRs open for failures when lld is /usr/bin/ld. Thanks
to recent commits from krion@ all unmaintained ports that had issues
have been addressed, except for print/openprinting (PR221809) and some
openal-related failures (PR226980). I'll try to take a look at the
openal issues; it's likely that the interim solution will be just to
set LLD_UNSAFE in all of the dependent ports.

The remaining 12 PRs are all for maintained ports. I believe that now
the only port responsible for a significant number of skipped
dependent ports is lang/ghc (PR226872).
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Heads-up: linker (lld) changes for amd64 coming soon

2018-04-04 Thread Ed Maste
On 29 March 2018 at 13:14, Ed Maste  wrote:
>
> There are now 14 PRs open for failures when lld is /usr/bin/ld.

Now down to 5:

PR 221800 - www/mod_jk
Appears to be an issue with libtool passing through linker flags. 0
dependent ports skipped.

PR 224673 - misc/seabios
Port maintainer has patch ready to be committed. 2 dependent ports skipped

PR 226872 - lang/ghc
Haskell compiler - the compiler builds fine by using ld.bfd via $LD,
but then the built compiler invokes ld. Report in the PR claims the
current version (8.4.1) includes some lld support so might "just work"
after the port's updated? 558 dependent ports skipped.

PR 226975 - x11/eaglemode
A common case due to disagreement about preemption of symbols with
protected visibility in a shared library. 0 dependent ports skipped.

PR 226980 - several ports using openal
Ports using openal failed due to the protected visibility symbol
preemption issue. LLD_UNSAFE has been added to many of them, with 14
more to go. As a group, 1 dependent port skipped.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Heads-up: linker (lld) changes for amd64 coming soon

2018-04-28 Thread Ed Maste
On 26 April 2018 at 23:07, Fāng-ruì Sòng  wrote:
>
> I'd like to experiment with LLD --warn-backrefs, which keeps compatibility
> with GNU linkers (bfd, gold) in terms of handling of LazyArchive and
> LazyObject (see
> http://lists.llvm.org/pipermail/llvm-dev/2018-April/122383.html for
> details).

Ah, thanks for the note. It was not documented in lld's man page; I
just added it upstream.

> I think a few representative FreeBSD packages may be a great playground to
> try --warn-backrefs
>
> Do you have some pointers on how I can build these packages locally with
> --warn-backrefs ?

Just adding LDFLAGS=-Wl,--warn-backrefs to /etc/make.conf should be
sufficient. I'm not sure of the proper way to replace the linker (with
a build from upstream that supports --warn-backrefs) or provide a
custom make.conf in Poudriere though, and hope that someone else can
provide some guidance on that.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Heads-up: linker (lld) changes for amd64 coming soon

2018-05-10 Thread Ed Maste
On 26 March 2018 at 22:14, Ed Maste  wrote:
> Some changes related to the amd64 linker are nearly ready to be
> committed (within a week or three), so I'm sending this notice to
> request any final comments or concerns before these changes are made.

It took somewhat longer than a week or three, but these changes will
now happen quite soon.

> 1. Kostik (kib@) has a patch to start using kernel ifunc, with the
> first use being Supervisor Mode Access Prevention (SMAP) on amd64.
> This relies on linker support that is available in the in-tree lld and
> in contemporary binutils ld.bfd from ports, but not in the in-tree
> ld.bfd 2.17.50.

This is ready to be committed at any time.

> 2. WITH_LLD_IS_LD controls whether /usr/bin/ld is ld.bfd or ld.lld,
> and thus the linker used for linking ports. I plan to switch this to
> default on.

There was one significant remaining issue in the ports tree with lld
as /usr/bin/ld: lang/ghc. This was due (at least in part) to a bug in
lld's note handling. The bug is now fixed upstream and in FreeBSD in
r333401.

The latest version of ghc claims to have improved support for using
lld as the linker, and a lang/ghc update is currently in progress
(PR227968). Once this is committed I will request one more exp-run
with lld. As long as those results are acceptable, I'll then make the
switch to install lld as /usr/bin/ld on amd64.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


HEADS-UP: Linker issues building amd64 kernels with config & make

2018-05-14 Thread Ed Maste
As of r333461 the amd64 kernel makes use of ifuncs, and requires
support in the linker. A safety belt added in r333470 enforces this,
and will produce an explicit error if the linker does not support
ifuncs.

lld is the default bootstrap linker for amd64 and has ifunc support.
The typical 'make buildworld' (or kernel-toolchain) followed by 'make
buildkernel' process will use lld and successfully link a working
kernel.

The old-style kernel build (using 'config' followed by a 'make' in the
kernel directory) uses the host linker (/usr/bin/ld). This still
defaults to GNU ld 2.17.50, which does not support ifuncs. This can be
worked around in one of two ways:

1. Install lld as the system linker (/usr/bin/ld), by adding
WITH_LLD_IS_LD to /etc/src.conf and building and install world.
WITH_LLD_IS_LD will become the default on amd64 in the near future -
I'm just waiting on updates to the lang/ghc port and another exp-run.

2. Override LD when you build the kernel:
$ LD=ld.lld make

These tool chain components will undergo additional changes for the next while.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: A head buildworld race visible in the ci.freebsd.org build history

2018-06-18 Thread Ed Maste
On 18 June 2018 at 19:29, Bryan Drewery  wrote:
>
> The error is coming from libarchive which had a change between those
> revisions:
>
>> 
>> r328332 | mm | 2018-01-24 06:24:17 -0800 (Wed, 24 Jan 2018) | 14 lines

Li-Wen reported that the build is done in a 11.1-rel jail though, so
the libarchive (or any userland) change shouldn't be responsible.

Can we update a canary builder to somewhere between r328278 and r88?
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Tool Chain Migration: objdump users, please test llvm-objdump

2018-06-20 Thread Ed Maste
Work is in progress to migrate fully to modern and permissively
licensed components for the tool chain. This includes moving away from
the three obsolete binutils components that are still in the base
system (as, ld, objdump). objdump is a tool to report information
about binary objects (such as headers, symbols, etc.), is not required
as a build tool, and in any case many uses of objdump are better
served by readelf.

For FreeBSD 12 I intend to remove GNU objdump 2.17.50. PR 229046[1] is
open to track tasks related to its removal, and users who need GNU
objdump can install an up-to-date version from the ports tree or the
binutils package.

That said, llvm includes a somewhat equivalent llvm-objdump, and it is
built by default in FreeBSD now. If llvm-objdump's command line option
support and output format is "close enough" to GNU objdump for most
users we may decide to install it as /usr/bin/objdump. Therefore, I
would like to ask users of GNU objdump in FreeBSD to give llvm-objdump
a try. Please let me know if it works for your uses, or describe
deficiencies that you found.

[1] https://bugs.freebsd.org/229046
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Tool Chain Migration: objdump users, please test llvm-objdump

2018-06-20 Thread Ed Maste
On 20 June 2018 at 18:25, Shawn Webb  wrote:
>
> Would you like me to quantify the compilation breakages due to the
> full llvm toolchain switch? If so, I can do that after July 12th.

Thanks Shawn, right now I'm interested specifically in llvm-objdump,
with the goal of sorting it out in advance of FreeBSD 12.

I think it's a worthwhile endeavour to quantify the breakage from
using all of the LLVM tools though, and if you're able to triage the
issues and submit LLVM, FreeBSD, or upstream port issues as
appropriate that would be much appreciated. (It's just not yet on the
critical path for me.)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Tool Chain Migration: objdump users, please test llvm-objdump

2018-06-21 Thread Ed Maste
On 20 June 2018 at 17:26, Alexander Richardson  wrote:
>
> When I made the change to use llvm-objdump in CheriBSD I had to change the
> objdump flags from -xrsSd to -r -s -p -S -d -h -l -t.

Ah yes, I recall discussing this now. Per GNU objdump's man page, -x
is equivalent to -a -f -h -p -r -t. llvm-objdump doesn't support
these:

-a archive headers
-f file headers

so we probably want to address those as well. We'll also need a man page.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Tool Chain Migration: objdump users, please test llvm-objdump

2018-06-21 Thread Ed Maste
On 21 June 2018 at 09:09, Ed Maste  wrote:
>
> We'll also need a man page.

I took a quick look at this, and in doing so found that the output
from "llvm-objdump --help" appears to be missing a large number of
single-letter options, so one more thing to sort out.

As it happens there are LLVM bugs open for a number of the
llvm-objdump issues (even including some I submitted but forgot
about):
https://bugs.llvm.org/buglist.cgi?component=llvm-objdump&list_id=140941&product=tools&query_format=advanced&resolution=---
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Migrating arm(v7) to LLD_BOOTSTRAP

2018-07-31 Thread Ed Maste
On 16 January 2018 at 18:45, Ed Maste  wrote:
> With the update to Clang/LLVM/lld 6.0.0 I believe lld is nearly ready
> to be used as the system linker for armv7, and I plan to enable
> LLD_BOOTSTRAP by default after a couple of WIP patches land and after
> a little more testing. This may happen a week or two from now. This
> should have little impact on port builds, because /usr/bin/ld will
> still be GNU ld.bfd (although there may be some unexpected fallout).

There was one significant issue preventing use of lld for armv7 - it
was not handling float type flags in the ELF header.

This was just fixed upstream, and I brought the change into FreeBSD in
r336972. I believe we're now ready to enable LLD_BOOTSTRAP by default
for armv7, and have posted the patch in review D16528[1] for
comments/feedback.

[1] https://reviews.freebsd.org/D16528
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Broken arm support in clang now?

2018-08-16 Thread Ed Maste
On 11 August 2018 at 20:45, Mark Millard via freebsd-toolchain
 wrote:
>
> Is the link command itself available? (The .../sys/*/kernel.full.meta
> likely has it if it is still around.)

I tried a tinderbox build right now and saw the lld warnings from
linking zfs.ko.  It appears to be fallout from the change to build
clang and lld only once for tinderbox, because we're invoking ld from
the ${HOST_TARGET} path:

/scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr/bin/ld
-m armelf_fbsd -Bshareable -znotext -d -warn-common --build-id=sha1
-o zfs.ko.full zfs.kld
/scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr/bin/ld:
warning: lld uses extended branch encoding, no object with
architecture supporting feature detected.
/scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr/bin/ld:
warning: lld may use movt/movw, no object with architecture supporting
feature detected.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Broken arm support in clang now?

2018-08-19 Thread Ed Maste
On 16 August 2018 at 10:49, Mark Millard  wrote:
>
> Ahh. Okay. 32-bit non-armv7+ cannot be fully llvm based.
> Intersting.

Indeed; there are a couple of patches in review upstream to address
the outstanding issues involved with using lld to link armv5/armv6.

> The implication would be that ld was then directly
> invoked instead of via cc (clang).

Yes, the issue I encountered appears to be a bug in recent logic that
shares a single clang and lld for multiple architectures in "make
tinderbox." It's directly invoking a newly-built lld.

The other issue observed with lld errors from linking arm or armv6
appears to be due to a failure to execute "make buildworld" or "make
kernel-toolchain" before "make buildkernel." In this case the build
invokes the host's system linker (ld). Previously on amd64 this was
the GNU BFD ld, not a cross-linker, and this resulted in an error. Now
that amd64's system ld is lld it's inherently a cross linker.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: elfcopy in src.conf

2018-09-11 Thread Ed Maste
On 11 September 2018 at 14:11, Sid  wrote:
> Hi,
> In src.conf, from 11.2 to 12-current, the elfcopy option was removed, but 
> objcopy still in the documentation for binutils. I suspect this is about the 
> toolchain too, and not only in the manpage for src.conf.
>
> Should objcopy be removed from binutils and from the manpage too?

I don't fully follow your question, but will provide some background
that I hope answers it - please let me know if it's still not clear.

In stable/11 we have a WITH_ELFCOPY_AS_OBJCOPY option which installs
ELF Tool Chain's elfcopy as objcopy; if not set the GNU binutils
objcopy is installed (and elfcopy is still available under that name).

In HEAD we always install ELF Tool Chain's elfcopy as objcopy, and the
objcopy man page is actually elfcopy's.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

2018-09-21 Thread Ed Maste
On 21 September 2018 at 01:59, Mark Millard via freebsd-toolchain
 wrote:
> In looking into another report about using devel/amd64-gcc to buld
> head I tried a build of -r338675 ( with WERROR= ). It got:
>
...
>
> Question:
>
> Is ignoring "-z ifunc-noplt" a problem for using what
> is built?

This will have no functional impact, should just result in a missed
optimization. (We ought to avoid passing it to non-lld linkers
though.)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

2018-09-21 Thread Ed Maste
On 21 September 2018 at 15:31, Mark Johnston  wrote:
>
> Perhaps the following?  It's not quite right since it'll still use
> -zifunc-noplt with an external LLVM toolchain, but I can't seem to
> figure out how to define a linker feature for only non-cross toolchains.
> In any case, we're going to upstream the option soon.

I wouldn't worry too much about out-of-tree since it will be upstream
soon as you say, otherwise looks good.

> +.if ${MACHINE_CPUARCH} == "amd64" || ${MACHINE_CPUARCH} == "i386"
> +.if defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc} == ""
>  .error amd64/i386 kernel requires linker ifunc support
>  .endif
> +.if defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc-noplt} != ""

Maybe roll && defined(LINKER_FEATURES) into the outer .if?
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

2018-09-24 Thread Ed Maste
On 23 September 2018 at 07:31, Michael Tuexen  wrote:
> Using this patch I was able to build/install world and kernel on an i386 
> system.
> However, after removing it, I can't build world then. When trying to compile a
> kernel "the old way" I end up with:
>
> tuexen@head:~/head/sys/i386/conf % config -g TCP
> WARNING: duplicate option `GEOM_PART_GPT' encountered.
> Kernel build directory is ../compile/TCP
> Don't forget to do ``make cleandepend && make depend''
> tuexen@head:~/head/sys/i386/conf % cd ../compile/TCP/
> tuexen@head:~/head/sys/i386/compile/TCP % make -j 6
> make: "../../../conf/../../../conf/kern.pre.mk" line 126: amd64/i386 kernel 
> requires linker ifunc support
>
> This is r338893.
>
> amd64 works without any problem. So this is i386 specific. Any idea how to 
> fix it?

This safety belt is in place to ensure we don't build a non-functional
kernel - now that the i386 kernel requires ifunc support using old GNU
ld results in a kernel that doesn't boot.

The workaround for the "old way" is to explicitly set LD=ld.lld in the
environment - "LD=ld.lld make -j 6" should work. More details in this
-arch thread, when amd64 encountered this hiccup:
https://lists.freebsd.org/pipermail/freebsd-arch/2018-May/018967.html

The same issue now affects i386 as it has started using ifuncs, and
will be resolved once we can switch i386's /usr/bin/ld to be lld,
which is waiting on ports fixes in PR214864.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: aarch64 head -r338921 vs. man ld vs. ld -v : man ld describes GNU when ld is lld

2018-09-25 Thread Ed Maste
On 25 September 2018 at 02:06, Mark Millard via freebsd-toolchain
 wrote:
> [This is based on buildworld buildkernel and installing.]
>
> But man ld reports GNU/BFD material:
>
> # man ld
> LD(1)GNU Development Tools   LD(1)
...

Odd. I see this on ref12-arm64.freebsd.org as well. It claims to be
r334753:336279M, which spans some related work (r335447).

Can you find instances of ld.1 in your install log?
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: aarch64 head -r338921 vs. man ld vs. ld -v : man ld describes GNU when ld is lld

2018-09-25 Thread Ed Maste
On 25 September 2018 at 11:59, Mark Millard  wrote:
>
> install  -o root -g wheel -m 444 ld.lld.1.gz  /usr/share/man/man1/
> rm -f /usr/share/man/man1/ld.1 /usr/share/man/man1/ld.1.gz;  install -l h -o 
> root -g wheel -m 444  /usr/share/man/man1/ld.lld.1.gz 
> /usr/share/man/man1/ld.1.gz

So this looks like ld.1 should indeed be a link to ld.lld.1.

Is it possible you're getting ld.1 from /usr/local? Does
/usr/share/man/man1/ld.1.gz exist?
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: aarch64 head -r338921 vs. man ld vs. ld -v : man ld describes GNU when ld is lld

2018-09-25 Thread Ed Maste
On 25 September 2018 at 14:21, Mark Millard  wrote:
>
> Did you notice the delete-old listing that I provided? It
> included: (>>> from delete-old prefix replaced below)

No I missed that.

> It appears that delete-old should not be listing
> /usr/share/man/man1/ld.1.gz as something to potentially delete
> in this aarch64 context.

Correct. I now have a fix waiting on re@ approval, thanks for the report.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


GNU binutils 2.17.50 retirement planning

2018-11-23 Thread Ed Maste
For some time we have been incrementally working to retire the use of
obsolete GNU Binutils 2.17.50 tools. At present we still install three
binutils by default:

as
ld.bfd
objdump

The intent is to retire all of these by FreeBSD 13. Depending on tool
and architecture we will just remove it, migrate to LLVM tools, or
rely on external toolchain components.

Retiring GNU as requires further investigation and effort as we have
some assembly files (for amd64 at least) which cannot be assembled by
Clang's integrated assembler. If Clang gains support for the required
functionality we'll switch to using IAS for all assembly files, and if
not we could rewrite the few assembly files to work with IAS.

ld.bfd is installed, but is not the default linker (/usr/bin/ld) on
amd64, arm64 and arm, and soon i386 as well. We can just stop
installing it at the appropriate time.

For objdump I have proposed installing LLVM's llvm-obdump as objdump,
in review D18307. It does not support all of the options that GNU
objdump does, but is usable for many common operations. In addition,
non-obsolete GNU objdump is available in the binutils port or package.
Please try out llvm-objdump and see if it supports the options you
need/use, and add a note in PR 229046 if not.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: GNU binutils 2.17.50 retirement planning

2018-11-26 Thread Ed Maste
On Sun, 25 Nov 2018 at 07:52, David Chisnall  wrote:
>
> We probably need to kill ld.bfd before 12.0.  It predates ifunc and so 
> interprets anything with an ifunc as requiring a copy relocation.

I posted https://reviews.freebsd.org/D18340 to stop installing ld.bfd
when LLD_IS_LD is enabled. This will have the effect of removing
ld.bfd on amd64 (where ifuncs are in use) as well as other
architectures which do not yet use ifuncs, but this seems like a
reasonable step in the process of removing these obsolete tools.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: GNU binutils 2.17.50 retirement planning

2018-11-26 Thread Ed Maste
On Sat, 24 Nov 2018 at 17:24, Charlie Li  wrote:
>
> some Makefile logic in stand/i386/btx specify a
> hard-coded /usr/bin/as without bootstrapped binutils, necessitating a
> symlink.

Which logic specifically? I can't seem to find it.

> If it is true that the only assembly files that clang IAS cannot
> assemble are for amd64 and i386, has there been any research into nasm
> and yasm at least? nasm is specified as a build dependency in certain
> multimedia/ ports, and yasm in gecko@, for amd64 and i386 assembly code.
> Both are licensed under some BSD licence variant.

The most significant issue is
sys/crypto/skein/amd64/skein_block_asm.s, and it makes extensive use
of GNU macro extensions. I have looked at nasm and yasm but believe
the macro extension support in those is less developed than in Clang's
IAS.

There are a number of files in stand/ tagged with CLANG_NO_IAS, in
gptzfsboot, cdboot, zfsboot, boot2, and pxeldr. These could likely be
removed now (they were added because Clang IAS did not support .codeNN
long ago), but they need to be tested first because the generated
output is slightly different.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: GNU binutils 2.17.50 retirement planning

2018-11-26 Thread Ed Maste
On Mon, 26 Nov 2018 at 10:52, Ed Maste  wrote:
>
> The most significant issue is
> sys/crypto/skein/amd64/skein_block_asm.s, and it makes extensive use
> of GNU macro extensions. I have looked at nasm and yasm but believe
> the macro extension support in those is less developed than in Clang's
> IAS.
>
> There are a number of files in stand/ tagged with CLANG_NO_IAS, in
> gptzfsboot, cdboot, zfsboot, boot2, and pxeldr. These could likely be
> removed now (they were added because Clang IAS did not support .codeNN
> long ago), but they need to be tested first because the generated
> output is slightly different.

In addition to those, on amd64 there are two other sets of .s files
currently assembled by GNU as:

* i386 boot components (stand/i386/{btx,kgzldr,libi386,mbr,pmbr})
* amd64 linuxulator (sys/amd64/linux{,32})

On i386 there are some others:

* kernel (sys/i386/i386)
* i386 linuxulator (sys/i386/linux)
* dtrace tests (cddl/contrib/opensolaris/cmd/dtrace/test/tst/i386)
* vm86 test tool (tools/test/vm86)

(Other architectures not yet investigated.)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Linking problem with lld

2019-02-22 Thread Ed Maste
On Fri, 22 Feb 2019 at 10:09, Willem Jan Withagen  wrote:
>
> My guess is that your linker doesn't support the new symbol versioning
> exports and since the symbols are hidden by default they aren't visible
> in the shared library. Previously there was a bug (since Luminous and
> the switch the cmake) where every public and private symbol was exported
> by librados.

lld is largely compatible with GNU ld / gold on the command-line and
in linker scripts and version scripts. Can you provide the error you
see or an example of one of the symbols with incorrect visibility?
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Optimization bug with floating-point?

2019-03-25 Thread Ed Maste
On Mon, 25 Mar 2019 at 14:32, Steve Kargl
 wrote:
>
> This is now
>
> https://bugs.llvm.org/show_bug.cgi?id=41224

Thanks for submitting a bug report to LLVM, I hope it gets some traction.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: add linker option for LIB32 step on PowerPC64

2019-05-03 Thread Ed Maste
On Thu, 2 May 2019 at 14:03, Alfredo Dal Ava Junior
 wrote:
>
> Hi all,
>
> I'm working on having PowerPC64 using LLVM by default, but LLD support for 32 
> bit seems to be incomplete.  As workaround I'm using ld.bfd (2.17) for the 
> LIB32 step.

Ok - eventual goal should be to have 32- and 64-bit linked with lld,
but I have no objection to an interim step that uses ld.bfd 2.17.50
for the 32-bit build. Note that there's a goal of removing GCC 4.2.1
and binutils 2.17.50 (requiring external toolchain for architectures
that have not migrated to clang/lld).

> I found no way to specify the linker for LIB32 step, so I created a variable 
> called LIB32LD that I pass to "make buildworld". Apparently we'll have to 
> make this workaround official, so I would like to know your thoughts about 
> this approach or if you have some other idea to share.

I think this would be fine, and it would default to ld.bfd on ppc64?
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Removing obsolete GDB 6.1.1 for FreeBSD 13

2020-12-02 Thread Ed Maste
We currently have an obsolete version of GDB 6.1 installed as
/usr/libexec/gdb, kept only for use by crashinfo(8), which extracts
some basic information from a kernel core dump after a crash. If the
gdb port is installed crashinfo will use that in preference to
/usr/libexec/gdb. If neither exists it will not perform any analysis,
reporting "Unable to find a kernel debugger."

GDB 6.1.1 was released in June 2004 and is long obsolete. It does not
support all of the architectures that FreeBSD does, and imposes
limitations on the FreeBSD kernel build - the continued use of DWARF2.

I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to
switch the GDB knob to default to NO in the near future. If the
crashinfo utility and related man pages do not already include
references to installing the gdb port/package I will add those before
making the change.

In the fullness of time we may use LLDB to extract the same
information, or provide other tooling to do so, but I do not want to
block GDB 6.1.1's removal on this.

Please let me know of any objections or comments.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Removing obsolete GDB 6.1.1 for FreeBSD 13

2020-12-02 Thread Ed Maste
On Wed, 2 Dec 2020 at 12:52, Warner Losh  wrote:
>
> even if lldb isn't a complete drop in replacement (I've not used it at all, 
> so I can't say one way or another).

Quick comment on this point - the FreeBSD Foundation has been
sponsoring Moritz Systems to improve LLDB on FreeBSD, and they've done
great work getting it into shape. Their work is in LLVM upstream now,
and they're iterating on fixing issues found by LLDB's test suite.
LLDB 12 should provide a capable userland debugging experience in
FreeBSD 13, although I suspect many users will still install the gdb
port or package for the familiar command line interface.

There's no FreeBSD kernel support in LLDB yet, but it's being investigated.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: Removing obsolete GDB 6.1.1 for FreeBSD 13

2020-12-04 Thread Ed Maste
Adding the FreeBSD-stable list to CC for more visibility.

On Wed, 2 Dec 2020 at 12:43, Ed Maste  wrote:
>
> I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to
> switch the GDB knob to default to NO in the near future. If the
> crashinfo utility and related man pages do not already include
> references to installing the gdb port/package I will add those before
> making the change.

The crashinfo man page now references the gdb port/package, and
crashinfo itself emits a message that the port/package should be
installed if kgdb is not found.

GDB's proposed retirement has now been added to
https://wiki.freebsd.org/DeprecationPlan.

I expect to make GDB default to NO next week, and then remove it from
the tree a week or two later, if there is no compelling objection.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


Re: clang options for load segments

2021-03-02 Thread Ed Maste
On Tue, 2 Mar 2021 at 14:37, Paul Floyd  wrote:
>
> I'll work on fixing it in Valgrind, but that is likely to be fair amount
> of work.

I guess that recent Clang+lld will produce the same PT_LOAD on Linux
too, so it seems like this is definitely something Valgrind will need
to handle.

> No need to hold your breath. Concerning the FreeBSD port I've been
> working on Valgrind on FreeBSD for about a year or so and now it's not
> too far from working as well on FreeBSD as it does on Linux*.
>
> Either install the devel/valgrind-devel package (note: not
> devel/valgrind) or even better build and install from my github repo
> https://github.com/paulfloyd/freebsd_valgrind. I have a commit bit for
> upstream Valgrind and am working on integrating FreeBSD support in the
> 'official' Valgrind. This probably won't be in the next release, 3.17,
> due soon, but I hope that it gets into the next one (3.17.1 or 3.18).
> And I'm always on the lookout for any user feedback :-) .

Thank you so much for this, I will be very happy to finally see
FreeBSD support upstream.

IMO we should look at removing devel/valgrind and replacing it with
valgrind-devel, given the amount of not-upstream work that exists in
both of them.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


[Differential] [Updated] D1327: Do not strip all when stripping an explicit symbol

2014-12-16 Thread emaste (Ed Maste)
emaste updated the summary for this revision.

REVISION DETAIL
  https://reviews.freebsd.org/D1327

To: emaste
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


[Differential] [Request, 3 lines] D1327: Do not strip all when stripping an explicit symbol

2014-12-16 Thread emaste (Ed Maste)
emaste created this revision.
emaste added a subscriber: freebsd-toolchain.

REVISION SUMMARY
  When asked to strip a specific symbol (-N) strip still defaulted to 
STRIP_ALL. In this case binutils defaults to stripping nothing (other than the 
requested symbol(s), of course), which makes a lot more sense.
  
  PR 196038
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196038

TEST PLAN
- reduced test case from PR
- build ffmpeg port

REVISION DETAIL
  https://reviews.freebsd.org/D1327

AFFECTED FILES
  contrib/elftoolchain/elfcopy/main.c

To: emaste
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


[Differential] [Closed] D1327: Do not strip all when stripping an explicit symbol

2014-12-17 Thread emaste (Ed Maste)
emaste closed this revision.
emaste updated this revision to Diff 2778.
emaste added a comment.

Closed by commit rS275862 (authored by @emaste).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D1327?vs=2767&id=2778#toc

REVISION DETAIL
  https://reviews.freebsd.org/D1327

AFFECTED FILES
  head/contrib/elftoolchain/elfcopy/main.c

To: emaste, imp
Cc: imp, freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


[Differential] [Request, 11 lines] D1341: Set up default shstrtab entries at initialization

2014-12-19 Thread emaste (Ed Maste)
emaste created this revision.
emaste added a subscriber: freebsd-toolchain.

REVISION SUMMARY
  If we use -R to remove all sections we still need a .shstrtab (which will 
itself be the only section entry). Do not wait until the addition of the first 
non-default entry to create the default ones.
  
  Elftoolchain ticket 463
  https://sourceforge.net/p/elftoolchain/tickets/463/

TEST PLAN
  ```
  touch empty.s
  make empty.o
  strip -o empty-stripped.o -R .text -R .data -R .bss -R .ARM.attributes -R 
.reginfo -R .gnu.attributes -R .MIPS.abiflags -R .pdr -R .xtensa.info empty.o
  readelf -S empty.o
  ```

REVISION DETAIL
  https://reviews.freebsd.org/D1341

AFFECTED FILES
  elfcopy/sections.c

To: emaste
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


[Differential] [Updated] D1341: Set up default shstrtab entries at initialization

2014-12-19 Thread emaste (Ed Maste)
emaste updated the test plan for this revision.

REVISION DETAIL
  https://reviews.freebsd.org/D1341

To: emaste
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


[Differential] [Closed] D1341: Set up default shstrtab entries at initialization

2014-12-22 Thread emaste (Ed Maste)
emaste closed this revision.
emaste updated this revision to Diff 2813.
emaste added a comment.

Closed by commit rS276061 (authored by @emaste).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D1341?vs=2791&id=2813#toc

REVISION DETAIL
  https://reviews.freebsd.org/D1341

AFFECTED FILES
  head/contrib/elftoolchain/elfcopy/sections.c

To: emaste, imp
Cc: imp, freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


[Differential] [Request, 191 lines] D1428: readelf: Handle note types from different operating systems

2015-01-03 Thread emaste (Ed Maste)
emaste created this revision.
emaste added a subscriber: freebsd-toolchain.

REVISION SUMMARY
  Previously elftoolchain readelf(1) only displayed correct names for Linux 
note types.
  Upstream elftoolchain ticket #473 
https://sourceforge.net/p/elftoolchain/tickets/473/

REVISION DETAIL
  https://reviews.freebsd.org/D1428

AFFECTED FILES
  readelf/readelf.c

To: emaste
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


[Differential] [Commented On] D1428: readelf: Handle note types from different operating systems

2015-01-03 Thread emaste (Ed Maste)
emaste added a comment.

>>! In D1428#3, @rpaulo wrote:
> This looks odd.  Why are we relying on magic numbers instead of 
> constants/enums like before?

Some of the constants in the previous version are Linux-specific, and don't 
exist in our ELF headers.

We could make up our own constants (e.g. NT_LINUX_AUXV) but it doesn't seem 
like that would provide much value. The same constant name may have different 
values on different OSes.

REVISION DETAIL
  https://reviews.freebsd.org/D1428

To: emaste
Cc: rpaulo, freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


[Differential] [Commented On] D1428: readelf: Handle note types from different operating systems

2015-01-04 Thread emaste (Ed Maste)
emaste added a comment.

>>! In D1428#6, @rpaulo wrote:
>
> The Linux note types are Linux specific.  Are you saying that FreeBSD reuses 
> them ?

Not quite, just that the note types are vendor-specific and in a namespace 
specific to the note name (vendor). `NT_PRSTATUS`, `NT_FPREGSET`, and 
`NT_FPREGSET` happen to have the same value on Linux and FreeBSD. We don't 
currently have definitions in our ELF headers for Linux-specific note types 
like NT_LWPSTATUS, and I'd find it somewhat odd to add them without somehow 
putting them in a namespace in the header.

REVISION DETAIL
  https://reviews.freebsd.org/D1428

To: emaste
Cc: rpaulo, freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


[Differential] [Closed] D1428: readelf: Handle note types from different operating systems

2015-01-05 Thread emaste (Ed Maste)
emaste closed this revision.
emaste updated this revision to Diff 3002.
emaste added a comment.

Closed by commit rS276705 (authored by @emaste).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D1428?vs=2980&id=3002#toc

REVISION DETAIL
  https://reviews.freebsd.org/D1428

AFFECTED FILES
  head/contrib/elftoolchain/readelf/readelf.c

To: emaste, kostikbel
Cc: rpaulo, freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


[Differential] [Changed Subscribers] D1446: Add the AArch64 llvm backend

2015-01-06 Thread emaste (Ed Maste)
emaste added a subscriber: freebsd-toolchain.

REVISION DETAIL
  https://reviews.freebsd.org/D1446

To: andrew, emaste, dim
Cc: freebsd-toolchain, emaste
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


[Differential] [Accepted] D1446: Add the AArch64 llvm backend

2015-01-06 Thread emaste (Ed Maste)
emaste accepted this revision.
This revision is now accepted and ready to land.

BRANCH
  /head

INLINE COMMENTS
  lib/clang/include/AArch64GenAsmMatcher.inc:1 Please unexpand these before 
checkin.
  
  SVN does the expansion on checkout. I'm not sure if they're collapsed on 
checkin, or stored verbatim, but don't want to find out :-)

REVISION DETAIL
  https://reviews.freebsd.org/D1446

To: andrew, dim, emaste
Cc: freebsd-toolchain, emaste
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


[Differential] [Commented On] D1446: Add the AArch64 llvm backend

2015-01-07 Thread emaste (Ed Maste)
emaste added a comment.

>>! In D1446#10, @andrew wrote:
> We will also need llvm r92 to build the kernel without using floating 
> point registers.

Can we bring this one directly into HEAD?

BRANCH
  /head

REVISION DETAIL
  https://reviews.freebsd.org/D1446

To: andrew, emaste, dim
Cc: freebsd-toolchain, emaste
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


[Differential] [Commented On] D1446: Add the AArch64 llvm backend

2015-01-07 Thread emaste (Ed Maste)
emaste added a comment.

I imported this change then merged to my arm64 branch and it looks fine to me.

REVISION DETAIL
  https://reviews.freebsd.org/D1446

To: dim, andrew, emaste
Cc: freebsd-toolchain, emaste
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


[Differential] [Changed Subscribers] D1468: Fix the ARM build of compiler-rt

2015-01-09 Thread emaste (Ed Maste)
emaste added a subscriber: emaste.

BRANCH
  /head

REVISION DETAIL
  https://reviews.freebsd.org/D1468

To: andrew, loos, sbruno, rpaulo, ian, dim, imp
Cc: emaste, freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


[Differential] [Updated] D1505: Enable building libclang_rt (asan, ubsan and profile) for selected arches

2015-01-12 Thread emaste (Ed Maste)
emaste added a comment.

> Apart from the bit of ugliness in lib/Makefile
Perhaps the ugliness needs a comment, at least.

Also a BSD.debug.mk entry for `WITH_DEBUG_FILES=yes`?

REVISION DETAIL
  https://reviews.freebsd.org/D1505

To: dim, andrew, bapt, imp, emaste
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"


  1   2   >