[Differential] [Commented On] D1826: libdwarf: Add symbol value when processing .rela relocations
emaste added a comment. See also D1819 REVISION DETAIL https://reviews.freebsd.org/D1826 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] [Accepted] D1819: libdwarf: Handle .rel relocations
rpaulo added a subscriber: rpaulo. rpaulo accepted this revision. rpaulo added a reviewer: rpaulo. rpaulo added a comment. This revision is now accepted and ready to land. Reviewed. REVISION DETAIL https://reviews.freebsd.org/D1819 To: emaste, gnn, rpaulo 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] [Updated] D1819: libdwarf: Handle .rel relocations
emaste added a reviewer: br. REVISION DETAIL https://reviews.freebsd.org/D1819 To: emaste, gnn, rpaulo, br 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] [Updated] D1826: libdwarf: Add symbol value when processing .rela relocations
emaste added reviewers: kostikbel, rpaulo. REVISION DETAIL https://reviews.freebsd.org/D1826 To: emaste, kostikbel, rpaulo 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, 6 lines] D1826: libdwarf: Add symbol value when processing .rela relocations
emaste created this revision. emaste added a subscriber: freebsd-toolchain. REVISION SUMMARY In practice .rela debug relocations often use the the .debug_* sections as the symbol, which has the value 0: ``` Relocation section '.rela.debug_info' at offset 0xd18 contains 205 entries: Offset Info Type Sym. ValueSym. Name + Addend 0006 001a000a R_X86_64_32 .debug_abbrev + 0 000c 001e000a R_X86_64_32 .debug_str + 0 0012 001e000a R_X86_64_32 .debug_str + 45 ``` so in those cases there is no difference if the symbol value is used in the relocation or not. It is not always the case though: ``` 0039 00270001 R_X86_64_64 0010 xen_pci_driver + 0 ``` REVISION DETAIL https://reviews.freebsd.org/D1826 AFFECTED FILES libdwarf/libdwarf_elf_init.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
Re: clang and scanbuild
On 11 Feb 2015, at 22:17, Craig Rodrigues rodr...@freebsd.org wrote:
We currently have a Jenkins job which checks out llvm trunk and builds
it like this:
svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
cd llvm
./configure --enable-optimized --disable-assertions --disable-docs
--enable-targets=host \
--with-c-include-dirs=${WORKDIR}/obj${WORKDIR}/src/tmp/usr/include \
--with-cxx-include-root=${WORKDIR}/obj${WORKDIR}/src/tmp/usr/include
gmake -j4
cp -p ./tools/clang/tools/scan-build/scan-build \
./tools/clang/tools/scan-build/scanview.css \
./tools/clang/tools/scan-build/sorttable.js \
Release/bin
cp -p ./tools/clang/tools/scan-build/ccc-analyzer \
./tools/clang/tools/scan-build/c++-analyzer \
Release/bin
We then do this to invoke scan-build over the FreeBSD tree:
/usr/bin/time -l \
env CCC_ANALYZER_CHECKER_DEADCODE=0 \
${SCAN_BUILD} \
--use-cc ${OBJ}${SRCDIR}/tmp/usr/bin/cc \
--use-c++ ${OBJ}${SRCDIR}/tmp/usr/bin/c++ \
-k -o $output make ${JFLAG} $MYFLAGS \
CROSS_COMPILER_PREFIX=${OBJ}${SRCDIR}/tmp/usr/bin/ $@
We can continue to do this, but I was wondering if:
(1) is there a FreeBSD port which has this stuff?
Yes, choose either lang/clang-devel, or lang/clangXY, where XY is the
version you are interested in.
(2) is there enough llvm source in FreeBSD that we can build this in
FreeBSD instead of checking out llvm source?
You can already run the analyzers with the clang executable in base,
unless you built your world using WITHOUT_CLANG_FULL. You do need perl
installed, of course.
-Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
clang and scanbuild
Hi,
We currently have a Jenkins job which checks out llvm trunk and builds
it like this:
svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
cd llvm
./configure --enable-optimized --disable-assertions --disable-docs
--enable-targets=host \
--with-c-include-dirs=${WORKDIR}/obj${WORKDIR}/src/tmp/usr/include \
--with-cxx-include-root=${WORKDIR}/obj${WORKDIR}/src/tmp/usr/include
gmake -j4
cp -p ./tools/clang/tools/scan-build/scan-build \
./tools/clang/tools/scan-build/scanview.css \
./tools/clang/tools/scan-build/sorttable.js \
Release/bin
cp -p ./tools/clang/tools/scan-build/ccc-analyzer \
./tools/clang/tools/scan-build/c++-analyzer \
Release/bin
We then do this to invoke scan-build over the FreeBSD tree:
/usr/bin/time -l \
env CCC_ANALYZER_CHECKER_DEADCODE=0 \
${SCAN_BUILD} \
--use-cc ${OBJ}${SRCDIR}/tmp/usr/bin/cc \
--use-c++ ${OBJ}${SRCDIR}/tmp/usr/bin/c++ \
-k -o $output make ${JFLAG} $MYFLAGS \
CROSS_COMPILER_PREFIX=${OBJ}${SRCDIR}/tmp/usr/bin/ $@
We can continue to do this, but I was wondering if:
(1) is there a FreeBSD port which has this stuff?
(2) is there enough llvm source in FreeBSD that we can build this in
FreeBSD instead of checking out llvm source?
--
Craig
___
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] D1819: libdwarf: Handle .rel relocations
imp accepted this revision. imp added a reviewer: imp. REVISION DETAIL https://reviews.freebsd.org/D1819 To: emaste, br, rpaulo, gnn, imp 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
Re: Resurrecting clang external toolchain support in Makefile.inc
Hi Warner, I like this patch better than the one I have. I’m not 100% sure the ‘else’ clause will work The else for CROSS_BINUTILS_PREFIX ? If so, yes, that appears to work: I'm building with in-tree binutils. Ok for this to be committed ? later, Peter. ___ 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: Resurrecting clang external toolchain support in Makefile.inc
On Feb 11, 2015, at 5:02 PM, Peter Grehan gre...@freebsd.org wrote:
Hi Bapt,
In my opinion we should track down the last traces of XFLAGS and turn them
into
proper XCFLAGS and XCXXFLAGS, the intent was to get rid of XFLAGS because the
name was confusing.
so instead of adding XFLAGS to XC*FLAGS, the XFLAGS should juste be converted
into XC*FLAGS directly in my opinion.
How about the appended ? It moves the sysroot definition into the non-GCC
XC/XCXXFLAGS defs, and renames XFLAGS to BFLAGS. This should be identical to
pre r273755 behaviour.
later,
Peter.
--- Makefile.inc1 (revision 278542)
+++ Makefile.inc1 (working copy)
@@ -348,16 +348,15 @@
SIZE=${XSIZE}
.if ${XCC:M/*}
-XFLAGS= --sysroot=${WORLDTMP}
.if defined(CROSS_BINUTILS_PREFIX)
# In the case of xdev-build tools, CROSS_BINUTILS_PREFIX won't be a
# directory, but the compiler will look in the right place for it's
# tools so we don't need to tell it where to look.
.if exists(${CROSS_BINUTILS_PREFIX})
-XFLAGS+= -B${CROSS_BINUTILS_PREFIX}
+BFLAGS+= -B${CROSS_BINUTILS_PREFIX}
.endif
.else
-XFLAGS+= -B${WORLDTMP}/usr/bin
+BFLAGS+= -B${WORLDTMP}/usr/bin
.endif
.if ${TARGET} == arm
.if ${TARGET_ARCH:M*hf*} !=
@@ -374,6 +373,8 @@
TARGET_ABI?= unknown
TARGET_TRIPLE?= ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd11.0
XCFLAGS+= -target ${TARGET_TRIPLE}
+XCFLAGS+=--sysroot=${WORLDTMP} ${BFLAGS}
+XCXXFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS}
.endif
.endif
I like this patch better than the one I have. I’m not 100% sure the ‘else’
clause will work, but it is certainly better than we have today.
Warner
___
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: Resurrecting clang external toolchain support in Makefile.inc
On Feb 11, 2015, at 7:14 PM, Peter Grehan gre...@freebsd.org wrote: Hi Warner, I like this patch better than the one I have. I’m not 100% sure the ‘else’ clause will work The else for CROSS_BINUTILS_PREFIX ? If so, yes, that appears to work: I'm building with in-tree binutils. Ok for this to be committed ? Yes. I’m happy. Warner ___ 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: Resurrecting clang external toolchain support in Makefile.inc
On Wed, Feb 11, 2015 at 11:55:17PM -0700, Warner Losh wrote: On Feb 11, 2015, at 7:14 PM, Peter Grehan gre...@freebsd.org wrote: Hi Warner, I like this patch better than the one I have. I’m not 100% sure the ‘else’ clause will work The else for CROSS_BINUTILS_PREFIX ? If so, yes, that appears to work: I'm building with in-tree binutils. Ok for this to be committed ? Yes. I’m happy. Ok for me as well! Best regards, Bapt pgpklV6hta4Jx.pgp Description: PGP signature
Re: Resurrecting clang external toolchain support in Makefile.inc
On Tue, Feb 10, 2015 at 07:50:59PM -0700, Warner Losh wrote:
On Feb 10, 2015, at 7:32 PM, Peter Grehan gre...@freebsd.org wrote:
Hi toolchain folk,
I've recently tried using the base system clang as an external toolchain
i.e.
make CROSS_COMPILER_PREFIX=/usr/bin/ buildworld
.. and found that this no longer works after r273755 which split XFLAGS
into XC/XCXXFLAGS. This appears to be because the XFLAGS definitions that
define --sysroot and -B options aren't being passed through to clang,
resulting in using header files from the host system.
My quick hack was
--- Makefile.inc1 (revision 278542)
+++ Makefile.inc1 (working copy)
@@ -374,6 +374,8 @@
TARGET_ABI?=unknown
TARGET_TRIPLE?= ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd11.0
XCFLAGS+= -target ${TARGET_TRIPLE}
+XCFLAGS+= ${XFLAGS}
+XCXXFLAGS+=${XFLAGS}
.endif
.endif
However, this doesn't look to be the right way to fix this.
Any opinions on a proper fix ?
I have a similar “fix” in my tree as well, but hadn’t pushed it because I
wasn’t quite sure the right way either.
Warner
In my opinion we should track down the last traces of XFLAGS and turn them into
proper XCFLAGS and XCXXFLAGS, the intent was to get rid of XFLAGS because the
name was confusing.
so instead of adding XFLAGS to XC*FLAGS, the XFLAGS should juste be converted
into XC*FLAGS directly in my opinion.
Best regards,
Bapt
pgpyZlqtlD99a.pgp
Description: PGP signature
