Re: Getting started with clang debuginfo
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 bad with > clang 8 on FreeBSD 12.1. On 13-CURRENT with clang 10 things are noticeably > worse. For GCC built binaries I'm not aware of any issues. > > I'm not familiar (yet) with the debuginfo code in Valgrind. > > To get me going, does anyone have any pointers to > - documentation on clang debuginfo > - any info on differences wrt GCC (I have seen that GCC does have some > debuginfo extensions) > - any tools that would be useful like ascii dumps Are you asking about tools to dump DWARF info? I've used dwarfdump (from ports) quite a bit in the past. readelf -w is similar and available in the base system. ___ 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
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
> > 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?
https://reviews.freebsd.org/D17279 for anyone else that would like to
review.
___
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
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:
> >
> > 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.)
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.
diff --git a/share/mk/bsd.linker.mk b/share/mk/bsd.linker.mk
index caf4fccbae0f..bee6a9e345dc 100644
--- a/share/mk/bsd.linker.mk
+++ b/share/mk/bsd.linker.mk
@@ -13,6 +13,9 @@
# linker support for that feature:
#
# - build-id: support for generating a Build-ID note
+# - filter:support for filter DSOs
+# - ifunc: support for GNU ifuncs
+# - ifunc-noplt: support for optimized ifunc calls
# - retpoline: support for generating PLT with retpoline speculative
# execution vulnerability mitigation
#
@@ -85,6 +88,7 @@ ${X_}LINKER_FEATURES+=filter
.endif
.if ${${X_}LINKER_TYPE} == "lld" && ${${X_}LINKER_VERSION} >= 6
${X_}LINKER_FEATURES+= retpoline
+${X_}LINKER_FEATURES+= ifunc-noplt
.endif
.endif
.else
diff --git a/sys/conf/kern.pre.mk b/sys/conf/kern.pre.mk
index 523cea605afd..911f1accf1f6 100644
--- a/sys/conf/kern.pre.mk
+++ b/sys/conf/kern.pre.mk
@@ -121,12 +121,16 @@ CFLAGS+= ${CONF_CFLAGS}
LDFLAGS+= -Wl,--build-id=sha1
.endif
-.if (${MACHINE_CPUARCH} == "amd64" || ${MACHINE_CPUARCH} == "i386") && \
-defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc} == ""
+.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} != ""
+LDFLAGS+= -Wl,-z -Wl,ifunc-noplt
+.endif
+.endif
.if ${MACHINE_CPUARCH} == "amd64"
-LDFLAGS+= -Wl,-z max-page-size=2097152 -Wl,-z common-page-size=4096
-Wl,-z -Wl,ifunc-noplt
+LDFLAGS+= -Wl,-z max-page-size=2097152 -Wl,-z common-page-size=4096
.endif
NORMAL_C= ${CC} -c ${CFLAGS} ${WERROR} ${PROF} ${.IMPSRC}
___
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: src/contrib/elftoolchain/elfcopy/sections.c underallocates for Elf64_Rela and Elf32_Rela?
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) { \
> 718 if ((REL##SZ = malloc(cap * \
> 719 sizeof(Elf##SZ##_Rel))) == NULL)\
> 720 err(EXIT_FAILURE, "malloc failed"); \
> 721 } \
> 722 if (nrels >= cap) { \
> 723 cap *= 2; \
> 724 if ((REL##SZ = realloc(REL##SZ, cap * \
> 725 sizeof(Elf##SZ##_Rel))) == NULL)\
> 726 err(EXIT_FAILURE, "realloc failed");\
> 727 } \
> 728 REL##SZ[nrels].r_offset = REL.r_offset; \
> 729 REL##SZ[nrels].r_info = REL.r_info; \
> 730 if (s->type == SHT_RELA)\
> 731 rela##SZ[nrels].r_addend = rela.r_addend; \
> 732 nrels++;\
> 733 } while (0)
>
> The context has:
>
> 687 Elf32_Rel *rel32;
> 688 Elf64_Rel *rel64;
> 689 Elf32_Rela *rela32;
> 690 Elf64_Rela *rela64;
>
> So for, say, COPYREL(rela,64), the macro uses sizeof(Elf64_Rel) instead
> of sizeof(ELF64_Rela) in malloc and realloc but Elf64_Rela is the
> larger structure of the two ELF64_ types (by also having .r_addend).
>
> The scan build on ci.freebsd.org complains about this:
>
> Result of 'realloc' is converted to a pointer of type 'Elf64_Rela', which is
> incompatible with sizeof operand type 'Elf64_Rel'
>
> So far it does not look like a false-positive to me.
Looks like a valid bug to me. I think the following patch is needed:
diff --git a/contrib/elftoolchain/elfcopy/sections.c
b/contrib/elftoolchain/elfcopy/sections.c
index b292d18693b4..92265289c7d1 100644
--- a/contrib/elftoolchain/elfcopy/sections.c
+++ b/contrib/elftoolchain/elfcopy/sections.c
@@ -716,13 +716,13 @@ filter_reloc(struct elfcopy *ecp, struct section *s)
#defineCOPYREL(REL, SZ) do { \
if (nrels == 0) { \
if ((REL##SZ = malloc(cap * \
- sizeof(Elf##SZ##_Rel))) == NULL)\
+ sizeof(*REL##SZ))) == NULL) \
err(EXIT_FAILURE, "malloc failed"); \
} \
if (nrels >= cap) { \
cap *= 2; \
if ((REL##SZ = realloc(REL##SZ, cap * \
- sizeof(Elf##SZ##_Rel))) == NULL)\
+ sizeof(*REL##SZ))) == NULL) \
err(EXIT_FAILURE, "realloc failed");\
} \
REL##SZ[nrels].r_offset = REL.r_offset; \
___
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: dtrace -G vs. -flto
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 dtrace -G works. clang -flto produces LLVM bitcode files, and gcc -flto produces ELF files with custom sections. dtrace -G works by looking for relocations against symbols named __dtrace_probe_*, and recording and overwriting the relocation address, but the object files generated when using -flto are really only meant for consumption by the static linker. I think it might be possible to implement USDT for clang using LLVM's patchpoint instrinsic, but this would still require some support in the compiler. Anyway, I don't think it'll be possible to reconcile -flto and dtrace -G without substantial 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: WITH_CTF vs -g
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 can always have -g in CTFFLAGS, because the stripping
> step
> takes care of the original DWARF data in any case. But I am not 100% sure
> about
> this.
>
> What do you think?
> Thanks!
Hi Andriy,
Are you planning to go through with this? I was just about to post this
exact question, but then I remembered that you already have. :)
FWIW, the diff I have in mind is below. It also removes some checks that
I think are unnecessary from bsd.{lib,prog}.mk. It is not fully tested,
but seems to work for me. I'm also not sure about unconditionally
passing -g to ctfconvert and ctfmerge.
Thanks,
-Mark
diff --git a/share/mk/bsd.lib.mk b/share/mk/bsd.lib.mk
index f0acf16..c6b689d 100644
--- a/share/mk/bsd.lib.mk
+++ b/share/mk/bsd.lib.mk
@@ -36,7 +36,7 @@ NO_WERROR=
.if defined(DEBUG_FLAGS)
CFLAGS+= ${DEBUG_FLAGS}
-.if ${MK_CTF} != "no" && ${DEBUG_FLAGS:M-g} != ""
+.if ${MK_CTF} != "no"
CTFFLAGS+= -g
.endif
.else
diff --git a/share/mk/bsd.own.mk b/share/mk/bsd.own.mk
index 486914b..32556a1 100644
--- a/share/mk/bsd.own.mk
+++ b/share/mk/bsd.own.mk
@@ -128,6 +128,7 @@ :
.if ${MK_CTF} != "no"
CTFCONVERT_CMD=${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
+DEBUG_FLAGS?= -g
.elif defined(.PARSEDIR) || (defined(MAKE_VERSION) && ${MAKE_VERSION} >=
520300)
CTFCONVERT_CMD=
.else
diff --git a/share/mk/bsd.prog.mk b/share/mk/bsd.prog.mk
index 340950a..e4f7104 100644
--- a/share/mk/bsd.prog.mk
+++ b/share/mk/bsd.prog.mk
@@ -20,7 +20,7 @@ NO_WERROR=
CFLAGS+=${DEBUG_FLAGS}
CXXFLAGS+=${DEBUG_FLAGS}
-.if ${MK_CTF} != "no" && ${DEBUG_FLAGS:M-g} != ""
+.if ${MK_CTF} != "no"
CTFFLAGS+= -g
.endif
.endif
___
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"
