[Bug 215455] AdressSanitizer provides memalign() confusing consumers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215455
Bug ID: 215455
Summary: AdressSanitizer provides memalign() confusing
consumers
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-toolchain@FreeBSD.org
Reporter: jbe...@freebsd.org
Some build systems test symbol availability without prototypes in case of
broken/incomplete headers or due to simplicity. For one, Firefox has
AC_CHECK_FUNCS(memalign) which fails on FreeBSD but defines HAVE_MEMALIGN with
ASan. The code can be unwrapped into the following:
$ cat a.c
char memalign();
int main()
{
memalign();
return 0;
}
$ cc a.c -fsanitize=address
$ echo $?
0
$ cc a.c
/tmp/a-294bd8.o: In function `main':
a.c:(.text+0x12): undefined reference to `memalign'
$ echo $?
1
--
You are receiving this mail because:
You are the assignee for the bug.
___
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"
[Bug 215455] AddressSanitizer unlike libc provides memalign() confusing consumers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215455 Jan Beich (mail not working) changed: What|Removed |Added Summary|AdressSanitizer provides|AddressSanitizer unlike |memalign() confusing|libc provides memalign() |consumers |confusing consumers -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 215455] AddressSanitizer unlike libc provides memalign() confusing consumers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215455 Dimitry Andric changed: What|Removed |Added Assignee|freebsd-toolchain@FreeBSD.o |d...@freebsd.org |rg | Status|New |In Progress CC||d...@freebsd.org, ||ema...@freebsd.org --- Comment #1 from Dimitry Andric --- This is similar to bug 215125, which is for mallinfo() and mallopt(). I submitted an upstream review at https://reviews.llvm.org/D27654, still awaiting approval. I will submit something similar for this one. -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
poudriere use for head or stable/11 variant: patch internal-paths to use?
[This question is biased to my powerpc family experiments, doing things directly on the powerpc family.] Unlike for "ports" in poudriere and -m none -f none -M use (ufs file system) the jail alternative seems to just be patches: jail . . . Here are the options associated with the jail command. . . . -P patch Apply the specified patch to the source tree before building the jail. but nothing seems to specify the form of the patch for paths: (I use svn for /usr/src historically: these are from svnlite diff outputs.) Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td === --- contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 310236) +++ contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) . . . vs. Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td === --- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td(revision 310236) +++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td(working copy) vs. whatever. What is expected for paths? (And I suggest the command documentation give an explicit hint or pointer to something that has a hint.) If I interpret the documents correctly poudriere will not use my /usr/src/ : -P patch-file is the technique and I need something like "-m svn+https". Why I care: I normally have patches for powerpc land as I experiment with libc++ and clang or devel/powerpc64-xtoolchain-gcc for targeting powerpc64 and powerpc buildworld and buildkernel (simplified statement). I also have my own KERNCONF's (that include the standard ones). Be it head or stable/11 for now I need a variation of them for my context, including building ports (at least for system-clang based experiments). Note: It may be some time before I do anything that adds kernel modules so kernel-building does not have to be involved at this time for powerpc64 or powerpc. But this might not last. === Mark Millard markmi at dsl-only.net ___ 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"
