On Mon, Jul 27, 2020 at 11:27:40AM +0200, Paul FLOYD wrote:
> Hi
>
> I'm investigating some of the remaining issues with Valgrind on FreeBSD. One
> of the two remaining major issues that I'm aware of is with Valgrind reading
> dwarf debuginfo from clang compiled binaries. The problem isn't too
On Fri, Sep 21, 2018 at 04:37:08PM -0400, Ed Maste wrote:
> 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
&
On Fri, Sep 21, 2018 at 02:54:04PM -0400, Ed Maste wrote:
> 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:
>
On Sun, Jul 08, 2018 at 08:47:38AM -0700, Mark Millard via freebsd-toolchain
wrote:
> src/contrib/elftoolchain/elfcopy/sections.c has and uses the macro:
>
> 716 #define COPYREL(REL, SZ) do { \
> 717 if (nrels == 0) {
On Tue, Nov 28, 2017 at 01:34:00AM +0100, Jan Beich wrote:
> I'd like to build www/firefox with both DTrace and LTO support. Both
> Clang and GCC emit code that dtrace(1) doesn't understand.
Unfortunately, both gcc and clang's LTO implementations are completely
incompatible with the way that dtrac
On Wed, Sep 10, 2014 at 08:23:21PM +0300, Andriy Gapon wrote:
>
> In my opinion WITH_CTF should imply -g in CFLAGS otherwise, as far as I can
> see,
> there is nothing to generate CTF data from. Forcing an end-user to remember
> to
> additionally pass -g is not nice.
>
> Also, I think that we
