Ed Maste emaste at freebsd.org wrote on
Wed May 23 14:18:34 UTC 2018 :
> On 23 May 2018 at 10:15, Rodney W. Grimes
> wrote:
> >> Author: eadler
> >> Date: Wed May 23 10:45:32 2018
> >> New Revision: 334089
> >> URL: https://svnweb.freebsd.org/changeset/base/334089
> >>
> >> Log:
> >> dumpon:
Jonathan T. Looney jtl at freebsd.org wrote on
Thu Jun 7 03:00:00 UTC 2018 :
> I believe the theory is that the compiler (remember, this is
> __builtin_memset) can optimize away portions of the zeroing, or can
> optimize zeroing for small sizes.
>
> For example, imagine you do this:
>
>
>From https://ci.freebsd.org/job/FreeBSD-head-powerpcspe-build/6174/consoleText
>:
--- all_subdir_usb/muge ---
cc1: warnings being treated as errors
/usr/src/sys/dev/usb/net/if_muge.c: In function 'lan78xx_chip_init':
/usr/src/sys/dev/usb/net/if_muge.c:1096: warning: implicit declaration of
Eitan Adler eadler at FreeBSD.org wrote on
Mon Jun 11 05:05:22 UTC 2018 :
. . .
> - * positive numbers. If val <= 0 then digits(val) == 0.
> + * non-negative numbers. If val <= 0 then digits(val) == 0.
> */
>
> -int
> +int __pure2
> digits(int val)
> {
> int cnt = 0;
> + if
Warner Losh imp at FreeBSD.org wrote on
Wed Jun 13 22:00:04 UTC 2018 :
> Author: imp
> Date: Wed Jun 13 22:00:02 2018
> New Revision: 335091
> URL:
> https://svnweb.freebsd.org/changeset/base/335091
>
>
> Log:
> Make it possible to use print_controller from another program
>
> Rename
https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/5974/consoleText shows:
--- all_subdir_usr.sbin/pmc ---
In file included from
/workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/ios:216:0,
from
Brad Davis brd at FreeBSD.org wrote on
Mon Jun 4 18:41:03 UTC 2018 :
> On Mon, Jun 4, 2018, at 10:57 AM, Rodney W. Grimes wrote:
. . .
> > Iirc some of the make release stuff calls into here, but that
> > may of changed to use src/Makefile targets. distrib-dirs comes
> > to mind.
>
> Sure, but
[Just fixing a dumb typo in a build number.]
On 2018-Jun-5, at 12:22 PM, Mark Millard wrote:
> On 2018-Jun-5, at 10:49 AM, Dimitry Andric wrote:
>
>> On 5 Jun 2018, at 15:03, Mark Millard via freebsd-toolchain
>> wrote:
>>>
>>>
On 2018-Jun-5, at 10:49 AM, Dimitry Andric wrote:
> On 5 Jun 2018, at 15:03, Mark Millard via freebsd-toolchain
> wrote:
>>
>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/5974/consoleText shows:
>>
>> --- all_subdir_usr.sbin/pmc ---
>> In file included from
>>
Cy Schubert Cy.Schubert at cschubert.com wrote on
Wed Jun 6 04:10:39 UTC 2018 :
> Oops, I should have pasted this into my previous email.
>
> --- cmd_pmc_filter.o ---
> /usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0
> --sysroot=/export/obj/opt/src/svn-current/amd64.amd64/tmp
>
Eitan Adler eadler at FreeBSD.org wrote on
Wed Jun 6 06:42:14 UTC 2018 :
> + err(1, "calloc for kern.smp.maxcpus", size);
What is "size" used for when the string makes no use of it?
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
https://ci.freebsd.org/job/FreeBSD-head-riscv64-build/9229/consoleText
--- utils.o ---
/usr/local/bin/riscv64-unknown-freebsd11.1-gcc
--sysroot=/workspace/obj/workspace/src/riscv.riscv64/tmp
-B/usr/local/riscv64-unknown-freebsd11.1/bin/ -O2 -pipe -march=rv64imafdc
-mabi=lp64d -g -MD
My brain finally engaged for showing exactly what files are included
for the gcc builds: the .meta files include that information explicitly
(along with other files that are opened during the operation).
amd64 is as I reported, just one header file from gcc: float.h .
powerpc64 builds
On 2018-Jun-29, at 2:37 PM, Mark Millard wrote:
> [I expect this is more than just amd64-gcc related but that is all
> that ci.freebsd.org normally builds via a devel/*-gcc .]
>
> On 2018-Jun-29, at 10:38 AM, John Baldwin wrote:
>
>> On 6/28/18 7:54 PM, Mark Millard wrote:
>>> On 2018-Jun-28,
[I expect this is more than just amd64-gcc related but that is all
that ci.freebsd.org normally builds via a devel/*-gcc .]
On 2018-Jun-29, at 10:38 AM, John Baldwin wrote:
> On 6/28/18 7:54 PM, Mark Millard wrote:
>> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote:
>>
>>> On 2018-Jun-28, at
> Author: emaste
> Date: Tue Jun 26 16:50:41 2018
> New Revision: 335672
> URL:
> https://svnweb.freebsd.org/changeset/base/335672
>
>
> Log:
> Build linprocfs and linsysfs also on arm64
>
> Sponsored by: Turing Robotic Industries
>
> . . .
These are the gcc/g++ 4.2.1 based targets.
For example . . .
https://ci.freebsd.org/job/FreeBSD-head-powerpc64-build/6261/consoleText
--- all_subdir_sbin/devd ---
/usr/src/sbin/devd/devd.cc: In member function 'std::string
config::shell_quote(const std::string&)':
[I used the wrong Email address the first time.]
On 2018-Jun-27, at 6:31 PM, Warner Losh wrote:
>
>
>
> On Wed, Jun 27, 2018, 7:27 PM Mark Millard wrote:
> These are the gcc/g++ 4.2.1 based targets.
>
> For example . . .
>
>
Stephen J. Kiernan stevek at FreeBSD.org
Wed Jun 20 00:41:33 UTC 2018
Author: stevek
Date: Wed Jun 20 00:41:30 2018
New Revision: 335399
URL:
https://svnweb.freebsd.org/changeset/base/335399
Log:
MAC/veriexec implements a verified execution environment using the MAC
framework.
. . .
-r335879 broke ci.freebsd.org's FreeBSD-head-amd64-build :
https://ci.freebsd.org/job/FreeBSD-head-amd64-build/
shows:
--- ia32_genassym.o ---
In file included from /usr/src/sys/compat/ia32/ia32_genassym.c:6:
In file included from /usr/src/sys/sys/systm.h:113:
/usr/src/sys/sys/kpilite.h:33:10:
On 2018-Jun-30, at 7:51 AM, John Baldwin wrote:
> On 6/29/18 2:37 PM, Mark Millard wrote:
>> [I expect this is more than just amd64-gcc related but that is all
>> that ci.freebsd.org normally builds via a devel/*-gcc .]
>
> As indicated by my other mail, this is i386 and amd64 specific as it
>
On 2018-Jun-30, at 9:29 AM, John Baldwin wrote:
> On 6/30/18 9:17 AM, Mark Millard wrote:
>> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote:
>>
>>> On 6/29/18 2:37 PM, Mark Millard wrote:
[I expect this is more than just amd64-gcc related but that is all
that ci.freebsd.org normally
On 2018-Jun-30, at 10:04 AM, Mark Millard wrote:
> On 2018-Jun-30, at 9:29 AM, John Baldwin wrote:
>
>> On 6/30/18 9:17 AM, Mark Millard wrote:
>>> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote:
>>>
On 6/29/18 2:37 PM, Mark Millard wrote:
> [I expect this is more than just
https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/8358/consoleText
--- all_subdir_armv8crypto ---
/usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46:10: fatal error: 'arm_neon.h'
file not found
#include
^~~~
1 error generated.
*** [armv8_crypto_wrap.o] Error code 1
On 2018-Jun-30, at 11:53 AM, John Baldwin wrote:
> On 6/30/18 10:19 AM, Mark Millard wrote:
>
>
> On 2018-Jun-30, at 10:04 AM, Mark Millard wrote:
>
>> On 2018-Jun-30, at 9:29 AM, John Baldwin wrote:
>>
>>> On 6/30/18 9:17 AM, Mark Millard wrote:
On 2018-Jun-30, at 7:51 AM, John
[Note: around -r33590{4,6,7,8} these build attempts broke
in some cases but FreeBSD-head-{amd64,i386,riscv64}-{images,testvm}
just was never built for such. FreeBSD-head-amd64-testvm
first fails at -r335904 but FreeBSD-head-amd64-images
built -r335904 and failed for -r335908. Both i386's jumped
Andriy Gapon avg at FreeBSD.org wrote on
Fri Jan 19 18:41:07 UTC 2018 :
> On 19/01/2018 20:30, Conrad Meyer wrote:
> > On Fri, Jan 19, 2018 at 9:37 AM, Rodney W. Grimes
> > wrote:
> >> If you think in assembler it is easy to understand why this is UB,
> >> most (all) architectures Right Logic or
Rodney W. Grimes freebsd at pdx.rh.CN85.dnsmgr.net wrote on
Fri Jan 19 18:39:03 UTC 2018 (quoting style(9)):
> I think everyone glossed over:
>
> Parts of a for loop may be left empty. Do not put declarations inside
> blocks unless the routine is unusually complicated.
>
> Perhaps
Conrad Meyer cem at freebsd.org wrote on
Fri Jan 19 05:07:22 UTC 2018 :
> The spec says the behavior is undefined; not that the compiler has to
> produce a warning or error message. The compiler *does* get to
> arbitrarily decide what it wants to do when it encounters UB. It is
> wholly free to
Warner Losh imp at bsdimp.com wrote on
Fri Jan 26 06:02:04 UTC 2018 :
> It's a flaw in C++ that you have a choice here. All dtors should be
> virtual because you never know when you'll have new derived classes and
> have to hunt down a hard-to-find bug because you didn't go back and make it
>
Ian Lepore ian at freebsd.org wrote on
Fri Jan 26 16:56:09 UTC 2018 :
> Modern compilers will warn about a class with virtual functions and no
> virtual dtor, so just blindly including it is more harmful than
> prophylactic these days, IMO.
More reliable is to have non-virtual destructors be,
Ian Lepore ian at freebsd.org wrote on
Tue Feb 6 19:35:21 UTC 2018 :
> I don't understand this idea of /usr/local "polluting" a system. It
> seems to me exactly the opposite would be the case... if I have found
> some 3rd party version of mktemp that I like better, it would be
> installed in
Brad Davis brd at FreeBSD.org wrote on
Thu Jul 26 17:11:15 UTC 2018 :
> On Thu, Jul 26, 2018, at 11:09 AM, Shawn Webb wrote:
> . . .
> > > -FILES= ${.CURDIR}/pf.in
> > > -FILES+= ${.CURDIR}/pf.include
> > > -FILES+= ${.CURDIR}/pf.ok
> > > +FILES!=
https://ci.freebsd.org/job/FreeBSD-head-mips-build/3577/consoleText shows:
--- tcp_usrreq.o ---
cc1: warnings being treated as errors
/usr/src/sys/netinet/tcp_usrreq.c: In function 'tcp_usr_send':
/usr/src/sys/netinet/tcp_usrreq.c:905: warning: unused variable 'sin'
[-Wunused-variable]
. . .
---
For example:
https://ci.freebsd.org/job/FreeBSD-head-powerpc64-build/6718/consoleText
reports:
--- all_subdir_sbin ---
/usr/src/sbin/devd/devd.cc: In function 'int my_system(const char*)':
/usr/src/sbin/devd/devd.cc:265: error: 'nullptr' was not declared in this scope
The following also fail:
On 2018-Jul-28, at 8:59 PM, Brad Davis wrote:
> On Sat, Jul 28, 2018, at 9:53 PM, Mark Millard wrote:
>> Brad Davis brd at FreeBSD.org wrote on
>> Thu Jul 26 17:11:15 UTC 2018 :
>>
>>> On Thu, Jul 26, 2018, at 11:09 AM, Shawn Webb wrote:
>>> . . .
> -FILES= ${.CURDIR}/pf.in
> Author: mmacy
> Date: Mon Jul 2 19:48:38 2018
> New Revision: 335873
> URL:
> https://svnweb.freebsd.org/changeset/base/335873
>
>
> Log:
> inline atomics and allow tied modules to inline locks
>
> - inline atomics in modules on i386 and amd64 (they were always
> inline on other
On 2018-Aug-1, at 12:57 AM, Konstantin Belousov wrote:
>
> On Tue, Jul 31, 2018 at 06:46:31PM -0700, Mark Millard via freebsd-amd64
> wrote:
>>> Author: mmacy
>>> Date: Mon Jul 2 19:48:38 2018
>>> New Revision: 335873
>>> URL:
>>> https://svnweb.freebsd.org/changeset/base/335873
>>>
>>>
>>>
Alan Somers asomers at freebsd.org wrote on
Mon Jul 30 21:08:18 UTC 2018 :
> On Mon, Jul 23, 2018 at 10:11 AM, Brad Davis > wrote:
> > Author: brd
> > Date: Mon Jul 23 16:11:03 2018
> > New Revision: 336640
> > URL: https://svnweb.freebsd.org/changeset/base/336640
> >
> > Log:
> > Add the
> Author: brd
> Date: Sat Aug 4 22:41:17 2018
> New Revision: 337340
> URL:
> https://svnweb.freebsd.org/changeset/base/337340
>
>
> Log:
> Move autofs related configs to usr.sbin/autofs/
>
> This is prep for pkgbase to have config files tagged as such.
>
> Approved by:will
For example:
https://lists.freebsd.org/pipermail/svn-src-head/2018-August/117572.html
(-r337849 based) shows:
install -N /usr/src/etc -l h -o root -g wheel -m 555
/usr/obj/usr/src/sparc64.sparc64/release/dist/base/root/.profile
/usr/obj/usr/src/sparc64.sparc64/release/dist/base/.profile
On Wed, Aug 15, 2018, at 9:21 AM, Mark Millard wrote:
>> For example:
>>
>> https://lists.freebsd.org/pipermail/svn-src-head/2018-August/117572.html
>> (-r337849 based) shows:
>>
>> install -N /usr/src/etc -l h -o root -g wheel -m 555 /usr/obj/usr/src/
>>
Examples appear to include:
#9029 for https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/
#1182 for https://ci.freebsd.org/job/FreeBSD-head-armv7-build/
#7274 for https://ci.freebsd.org/job/FreeBSD-head-powerpc-build/
#7039 for https://ci.freebsd.org/job/FreeBSD-head-powerpc64-build/
#7331 for
For example:
https://ci.freebsd.org/job/FreeBSD-head-powerpc64-build/6945/consoleText shows:
(gcc 4.2.1, -r337652 for 6944 built)
--- all_subdir_cddl/usr.sbin ---
In file included from
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_pool.h:37,
from
[armv6 and risk64 built okay. But
mips, mips64, powerpc, powerpc64, powerpcspe,
and sparc64 are failing. By contrast, -r336667
built okay for these, but the jump to -r337671
or later jumped to failure.]
For example . . .
https://ci.freebsd.org/job/FreeBSD-head-powerpc64-build/6951/consoleText
For the below I wonder if graphics/drm-stable-kmod
would be correct for old powerpc64 PowerMac's and
such.
Presuming graphics/drm-legacy-kmod (I do not know):
Tier 2, old equipment, etc. so it may just be an item
for handling questions on the lists rather than making
a mess instead of the below
-r338057 built fine for both then:
https://ci.freebsd.org/job/FreeBSD-head-amd64-testvm/9265/console
of -r338065 shows:
(so after "deprecation of arc4random_stir and arc4random_addrandom")
19:38:13 + sudo chroot ufs env 'ASSUME_ALWAYS_YES=yes' pkg update
19:38:13 Bad system call
19:38:13 Build
I'm just using this move as an example for some more
general questions.
After this change when I look at:
https://www.freebsd.org/cgi/man.cgi?query=devfs.conf=0=5=FreeBSD+12-current=default=html
I see in the man page:
FILES
/etc/devfs.conf
/usr/share/examples/etc/devfs.conf
So . . .
https://ci.freebsd.org/job/FreeBSD-head-sparc64-build/8759/consoleText shows
( -r336526 ):
--
>>> Kernel build for GENERIC completed on Fri Jul 20 00:58:39 UTC 2018
--
+ cd
[Li-Wen Hsu: Does Ian Lepore's reply put this in your area?]
On 2018-Jul-19, at 6:51 PM, Ian Lepore wrote:
> On Thu, 2018-07-19 at 18:13 -0700, Mark Millard wrote:
>> https://ci.freebsd.org/job/FreeBSD-head-sparc64-build/8759/consoleTex
>> t shows
>> ( -r336526 ):
>>
>>
On 2018-Jul-1, at 6:34 AM, Mark Millard wrote:
> My brain finally engaged for showing exactly what files are included
> for the gcc builds: the .meta files include that information explicitly
> (along with other files that are opened during the operation).
>
> amd64 is as I reported, just one
> Author: br
> Date: Thu Jul 19 13:02:29 2018
> New Revision: 336482
> URL:
> https://svnweb.freebsd.org/changeset/base/336482
>
>
> Log:
> PROFILE, TESTS and CXX build options are no longer broken for RISC-V.
>
> . . .
https://ci.freebsd.org/job/FreeBSD-head-riscv64-build/9580/consoleText
I'm not sure if the following is intended or not.
I tried using
beastie_disable="YES"
loader_color="NO"
in boot/loader.conf on head -r338341 .
The default colors are still changed during:
(some characters are filtered out)
QUOTE
Setting currdev to disk2p2:
https://ci.freebsd.org/job/FreeBSD-head-riscv64-build/10428/consoleText
shows:
--- objcopy.full ---
cc -O2 -pipe -I/workspace/src/contrib/elftoolchain/libelftc
-I/workspace/src/contrib/elftoolchain/libpe
-I/workspace/src/contrib/elftoolchain/common -DWITH_PE=1 -I. -g -std=gnu99
Eitan Adler lists at eitanadler.com wrote on
Thu Jul 5 00:56:02 UTC 2018 :
> On Tue, 3 Jul 2018 at 08:22, John Baldwin > wrote:
> > since GCC usually breaks
> > them.
>
>
> Could you explain what you mean or point to a prior conversation?
I'll take a stab at it without giving much for
These are the gcc 4.2.1 32-bit architectures that are broken.
And example is . . .
https://ci.freebsd.org/job/FreeBSD-head-mips-build/3186/consoleText shows:
--- all_subdir_usr.bin ---
cc1: warnings being treated as errors
/usr/src/usr.bin/netstat/inet.c: In function 'sotoxsocket':
> Author: brooks
> Date: Thu Jul 5 17:02:10 2018
> New Revision: 336002
> URL:
> https://svnweb.freebsd.org/changeset/base/336002
>
>
> Log:
> Work around lame warnings in ancient gcc on 32-bit platforms.
>
> Fixes r335979.
[The below are the gcc 4.2.1 based 32-bit architectures.]
Examples:
https://ci.freebsd.org/job/FreeBSD-head-armv7-build/568/console shows:
18:54:11
--- _bootstrap-tools-usr.sbin/config ---
18:54:11
mkmakefile.o: In function `dump_nvlist':
18:54:11
/usr/src/usr.sbin/config/mkmakefile.c:287: undefined reference to
`cnvlist_get_string'
18:54:11
[PostBuildScript] - Executing post build scripts.
[FreeBSD-head-armv6-build] $ /bin/sh -xe /tmp/jenkins5219713071838772045.sh
+ ./freebsd-ci/artifact/post-link.py
/usr/local/lib/libpython3.6m.so.1.0: Undefined symbol "getrandom@FBSD_1.5"
Build step 'Execute Scripts' changed build result to
https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/8461/consoleText shows:
===> share/man/man4/man4.aarch64 (distribute) cd
/usr/src/share/man/man4/man4.aarch64; make __MAKE_CONF=/dev/null
SRCCONF=/dev/null install installconfig -DNO_SUBDIR
Eugene Grosbein eugen at grosbein.net wrote on
Sat Jul 7 21:14:06 UTC 2018 :
> 07.07.2018 22:02, Andrew Gallatin wrote:
>
> > One thing that was tangentially brought up is that the ability
> > to compile out-of-tree modules requires keeping the kernel-headers
> > around. So we may need to
Using armv7 as an example . . .
https://ci.freebsd.org/job/FreeBSD-head-armv7-build/616/consoleText shows:
--- pci_host_generic.o ---
/usr/src/sys/dev/pci/pci_host_generic.c:107:3: error: use of undeclared
identifier 'CPU_IMPL_CAVIUM'
{CPU_IMPL_CAVIUM, CPU_PART_THUNDERX2, 0, 0,
On 2018-Jul-3, at 10:06 AM, Li-Wen Hsu wrote:
> On Tue, Jul 3, 2018 at 5:30 PM Bryan Drewery wrote:
>>
>> On 7/2/2018 10:46 PM, Mark Millard wrote:
>>> -r335879 broke ci.freebsd.org's FreeBSD-head-amd64-build :
>>>
>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-build/
>>>
>>> shows:
[Note: mips64 built for -r336251 but failed for -r336252 and -r336253 .]
An example (mips64):
--- all_subdir_stand ---
cc1: warnings being treated as errors
/usr/src/stand/libsa/geli/geliboot_crypto.c: In function 'geliboot_crypt':
/usr/src/stand/libsa/geli/geliboot_crypto.c:45: warning: 'blks'
On 2018-Jun-28, at 6:04 PM, Mark Millard wrote:
> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote:
>
>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed)
>> for FreeBSD-head-amd64-gcc. It looked to me like the most likely
>> breaking-change was the following but I've not tried
On 2018-Jun-28, at 5:39 PM, Mark Millard wrote:
> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed)
> for FreeBSD-head-amd64-gcc. It looked to me like the most likely
> breaking-change was the following but I've not tried personal
> builds to confirm.
> ]
>
> It looks to me
[ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed)
for FreeBSD-head-amd64-gcc. It looked to me like the most likely
breaking-change was the following but I've not tried personal
builds to confirm.
]
It looks to me that:
> Author: jhb
> Date: Thu Jun 28 21:26:14 2018
> New
clang example:
( https://ci.freebsd.org/job/FreeBSD-head-amd64-build/9257/consoleText )
--- key_debug.o ---
/usr/src/sys/netipsec/key_debug.c:89:1: error: no previous prototype for
function 'kdebug_sadb_type' [-Werror,-Wmissing-prototypes]
kdebug_sadb_type(uint8_t type)
^
On 2018-Oct-30, at 3:23 PM, Alexander Richardson
wrote:
> . . .
> Before this change obj->textsize was always set as the end of
> PT_LOAD[0]. Now it will contain everything up to the end of the last
> PT_LOAD with execute permissions. In the binary you dumped this is
> PT_LOAD[0] both before
On 2018-Oct-31, at 11:53 AM, Alexander Richardson
wrote:
> On Wed, 31 Oct 2018 at 18:38, Mark Millard
> wrote:
>>
>> On 2018-Oct-30, at 3:23 PM, Alexander Richardson > freebsd.org> wrote:
>>
>>> . . .
>>> Before this change obj->textsize was always set as the end of
>>> PT_LOAD[0]. Now it
Konstantin Belousov kostikbel at gmail.com wrote on
Tue Oct 30 18:04:04 UTC 2018 :
> On Tue, Oct 30, 2018 at 03:32:40PM +, Alexander Richardson wrote:
> > On Tue, 30 Oct 2018 at 10:17, Michael Tuexen
> > wrote:
> > >
> > > > On 29. Oct 2018, at 22:08, Alex Richardson
> > > > wrote:
> > > >
Alexander Richardson arichardson at freebsd.org wrote on
Tue Oct 30 15:33:00 UTC 2018 :
> On Tue, 30 Oct 2018 at 10:17, Michael Tuexen
> wrote:
> >
> > > On 29. Oct 2018, at 22:08, Alex Richardson
> > > wrote:
> > >
> > > Author: arichardson
> > > Date: Mon Oct 29 21:08:02 2018
> > > New
On 2018-Oct-30, at 2:23 PM, Alexander Richardson
wrote:
> On Tue, 30 Oct 2018 at 18:19, Mark Millard
> wrote:
>>
>> Alexander Richardson arichardson at freebsd.org wrote on
>> Tue Oct 30 15:33:00 UTC 2018 :
>>
>>> On Tue, 30 Oct 2018 at 10:17, Michael Tuexen
>>> wrote:
> On
On 2018-Oct-30, at 2:40 PM, Alexander Richardson
wrote:
> On Tue, 30 Oct 2018 at 21:32, Mark Millard
> wrote:
>>
>>
>>
>> On 2018-Oct-30, at 2:23 PM, Alexander Richardson > freebsd.org> wrote:
>>
>>> On Tue, 30 Oct 2018 at 18:19, Mark Millard
>>> wrote:
Alexander Richardson
On 2018-Nov-2, at 11:50 AM, Konstantin Belousov wrote:
> On Fri, Nov 02, 2018 at 10:38:08AM -0700, Mark Millard wrote:
>> . . .
>
> There seems to be an issue with the direct execution mode on ppc.
> Even otherwise working ld-elf.so.1 segfaults if I try to use it as
> standalone binary.
>
>
On 2018-Nov-3, at 12:04 PM, Mark Millard wrote:
> On 2018-Nov-3, at 8:49 AM, Konstantin Belousov wrote:
>
>> On Fri, Nov 02, 2018 at 05:51:25PM -0700, Mark Millard wrote:
>>> On 2018-Nov-2, at 11:50 AM, Konstantin Belousov
>>> wrote:
>>>
On Fri, Nov 02, 2018 at 10:38:08AM -0700, Mark
On 2018-Nov-3, at 8:49 AM, Konstantin Belousov wrote:
> On Fri, Nov 02, 2018 at 05:51:25PM -0700, Mark Millard wrote:
>> On 2018-Nov-2, at 11:50 AM, Konstantin Belousov
>> wrote:
>>
>>> On Fri, Nov 02, 2018 at 10:38:08AM -0700, Mark Millard wrote:
. . .
>>>
>>> There seems to be an
On 2018-Nov-3, at 12:51 PM, Konstantin Belousov wrote:
> On Sat, Nov 03, 2018 at 12:04:53PM -0700, Mark Millard wrote:
>> 80903 ld-elf.so.1 CALL
>> mmap(0x1,0xb000,0,0x6010,0x,0x1,0,0)
>> 80903 ld-elf.so.1 RET mmap -1 errno 12 Cannot allocate memory
>
> This is the
On 2018-Nov-1, at 5:41 PM, Konstantin Belousov wrote:
> On Tue, Oct 30, 2018 at 12:45:13PM -0700, Mark Millard wrote:
>> Konstantin Belousov kostikbel at gmail.com wrote on
>> Tue Oct 30 18:04:04 UTC 2018 :
>>
>>> On Tue, Oct 30, 2018 at 03:32:40PM +, Alexander Richardson wrote:
On
On 2018-Nov-2, at 8:52 AM, Konstantin Belousov wrote:
> On Fri, Nov 02, 2018 at 08:30:17AM -0700, Mark Millard wrote:
>> Breakpoint 4, reloc_non_plt (obj=0x41041000, obj_rtld=0x1801cc7, flags=4,
>> lockstate=0x0) at /usr/src/libexec/rtld-elf/powerpc/reloc.c:338
>> 338
On 2018-Nov-2, at 4:38 AM, Konstantin Belousov wrote:
> On Fri, Nov 02, 2018 at 12:16:23AM -0700, Mark Millard wrote:
>> It stops when the dcbst in __syncicache runs into an address in
>> the p_align 65536 caused hole between the two PT_LOAD's with PF_X.
>> /bin/ls itself has such a hole, as
[The backtrace confirms what I reported to Alexander Richardson
and Shawn Webb earlier.]
On 2018-Nov-1, at 6:40 PM, Mark Millard wrote:
> On 2018-Nov-1, at 5:41 PM, Konstantin Belousov wrote:
>
>> On Tue, Oct 30, 2018 at 12:45:13PM -0700, Mark Millard wrote:
>>> Konstantin Belousov kostikbel
[I trace code associated with bl <1322.plt_call.getenv>
in the two contexts and extend the range over which things
appear to match: up to some point after the branch
b <__glink_PLTresolve> .]
On 2018-Nov-6, at 19:12, Mark Millard wrote:
> [I've present a little information about the
[I've present a little information about the longer-existing
failure's odd backtrace for /libexec/ld-elf.so.1 /bin/ls
--but on powerpc64 FreeBSD instead of 32-bit powerpc FreeBSD.]
On 2018-Nov-2, at 11:50, Konstantin Belousov wrote:
> On Fri, Nov 02, 2018 at 10:38:08AM -0700, Mark Millard
[I note what I've failed to find a way to investigate.]
On 2018-Nov-7, at 11:53, Mark Millard wrote:
> [I trace code associated with bl <1322.plt_call.getenv>
> in the two contexts and extend the range over which things
> appear to match: up to some point after the branch
> b
John Baldwin jhb at FreeBSD.org wrote on
Wed Nov 7 21:36:02 UTC 2018 :
> On 11/7/18 1:01 PM, Ed Schouten wrote:
> > Op wo 7 nov. 2018 om 19:32 schreef John Baldwin :
> >> Modified: head/sys/kern/imgact_elf.c
> >> ==
> >>
On Fri, Aug 31, 2018 at 02:20:09PM +, Glen Barber wrote:
> > On Fri, Aug 31, 2018 at 08:51:29AM -0400, Ed Maste wrote:
> > > On 30 August 2018 at 22:46, Glen Barber wrote:
> > > >
> > > > As I look closer at the log, I have a sneaking suspicion this may have
> > > > been a transient. I'm
On 2018-Aug-31, at 9:40 AM, Glen Barber wrote:
> On Fri, Aug 31, 2018 at 09:34:00AM -0700, Mark Millard wrote:
>> On Fri, Aug 31, 2018 at 02:20:09PM +, Glen Barber wrote:
On Fri, Aug 31, 2018 at 08:51:29AM -0400, Ed Maste wrote:
> On 30 August 2018 at 22:46, Glen Barber wrote:
John Baldwin jhb at FreeBSD.org wrote on
Thu Sep 20 16:39:27 UTC 2018 :
> On 9/20/18 8:54 AM, Mark Johnston wrote:
> > On Sun, Jul 15, 2018 at 12:23:11AM +, Matt Macy wrote:
> >> Author: mmacy
> >> Date: Sun Jul 15 00:23:10 2018
> >> New Revision: 336299
> >> URL:
[I've got a historical WERROR= used in my amd64-gcc based builds.]
On 2018-Sep-20, at 6:05 PM, Mark Millard wrote:
> Li-Wen Hsu lwhsu at freebsd.org wrote on
> Thu Sep 20 22:10:19 UTC 2018 :
>
>> On Thu, Sep 20, 2018 at 10:06 PM Mark Johnston wrote:
>>>
>>> On Thu, Sep 20, 2018 at
Li-Wen Hsu lwhsu at freebsd.org wrote on
Thu Sep 20 22:10:19 UTC 2018 :
> On Thu, Sep 20, 2018 at 10:06 PM Mark Johnston wrote:
> >
> > On Thu, Sep 20, 2018 at 09:39:24AM -0700, John Baldwin wrote:
> > > On 9/20/18 8:54 AM, Mark Johnston wrote:
> > > > On Sun, Jul 15, 2018 at 12:23:11AM +,
[Similar to an old note about -r336099 .]
Both:
https://ci.freebsd.org/job/FreeBSD-head-amd64-build/10300/consoleText
https://ci.freebsd.org/job/FreeBSD-head-i386-build/9428/consoleText
show (from the amd64 example):
===> zlib (install)
install -N /usr/src/etc -T release -o root -g wheel -m
[I was asked what the fix might be. So I suggest specifics.]
On 2018-Sep-16, at 10:06 AM, Mark Millard wrote:
> Looks like this head/ObsoleteFiles.inc update has a typo
> in each thing added to OLD_FILES . . .
>
> # ls -lTdt /usr/tests/usr.bin/indent/*
> -r--r--r-- 1 root wheel 121 Sep 13
Mark Johnston markj at freebsd.org wrote on
Thu Sep 20 15:54:08 UTC 2018 :
> On Sun, Jul 15, 2018 at 12:23:11AM +, Matt Macy wrote:
> > Author: mmacy
> > Date: Sun Jul 15 00:23:10 2018
> > New Revision: 336299
> > URL: https://svnweb.freebsd.org/changeset/base/336299
> >
> > Log:
> > msun:
Warner Losh imp at FreeBSD.org wrote on
Tue Nov 20 07:11:24 UTC 2018 :
> Instead, used fixed constants because there's no way to say ceil(X)
> for integer math. . . .
For a ratio of unsigned integers, with 0
// ceil_x_div_y(x,y), given 0https://lists.freebsd.org/mailman/listinfo/svn-src-head
To
Mateusz Guzik mjg at FreeBSD.org wrote on
Tue Nov 20 14:58:42 UTC 2018 :
> +#if defined(__mips__) || defined(__powerpc__)
> +#define UNR64_LOCKED
> +#endif
But on powerpc64 ( system clang from head -r339076 ):
# clang -dM -E -x c /dev/null | grep -i __power
#define __POWERPC__ 1
#define
Looks like this head/ObsoleteFiles.inc update has a typo
in each thing added to OLD_FILES . . .
# ls -lTdt /usr/tests/usr.bin/indent/*
-r--r--r-- 1 root wheel 121 Sep 13 22:53:30 2018
/usr/tests/usr.bin/indent/Kyuafile
. . .
-r--r--r-- 1 root wheel 295 Sep 13 22:53:29 2018
[I did not deal with translating register usage correctly.]
> On 2019-Apr-27, at 01:50, Mark Millard wrote:
>
> Justin Hibbits jhibbits at FreeBSD.org wrote on
> Fri Apr 26 16:21:47 UTC 2019 :
>
>> This actually uses 'cmpb' which is only available on PowerISA 2.05+, so
>> I'll need to pull it
Justin Hibbits jhibbits at FreeBSD.org wrote on
Fri Apr 26 16:21:47 UTC 2019 :
> This actually uses 'cmpb' which is only available on PowerISA 2.05+, so
> I'll need to pull it out for now, and re-enable it once we have
> ifuncs. As it stands, this commit broke the G5 and POWER4/POWER5.
As I
Using if_igb.ko and if_em.ko as examples:
-r324406 (2017-Oct-7) used relative symbolic links (via a different technique)
[sbruno]
-r324500 (3 days later) used hard links (ian, with sbruno submitting)
-r346441 (2019-Apr-20) is back to relative symbolic links. (asomers)
Sbruno or Ian might want
1 - 100 of 166 matches
Mail list logo
