re: current USE_SSP=yes build failure
rudolf writes:
> Hi,
>
> I have "USE_SSP=yes" in mk.conf and the build is failing with:
>
> --- dependall-drivers ---
> /usr/xsrc/external/mit/xorg-server/dist/hw/xfree86/drivers/modesetting/drmmode_display.c:
>
> In function 'drmmode_crtc_gamma_set':
> /usr/xsrc/external/mit/xorg-server/dist/hw/xfree86/drivers/modesetting/drmmode_display.c:1768:1:
>
> error: stack protector not protecting local variables: variable length
> buffer [-Werror=stack-protector]
> 1768 | drmmode_crtc_gamma_set(xf86CrtcPtr crtc, uint16_t * red,
> uint16_t * green,
>| ^~
>
> Is this to be expected? Am I doing something wrong? The function itself
> is very simple.
ah, this comes from the call this function makes:
if (drmmode_crtc->use_gamma_lut) {
drmmode_set_gamma_lut(drmmode_crtc, red, green, blue, size);
which is:
drmmode_set_gamma_lut(drmmode_crtc_private_ptr drmmode_crtc,
uint16_t * red, uint16_t * green, uint16_t * blue,
int size)
[ ... ]
struct drm_color_lut lut[size];
i'll figure out a fix or workaround. thanks.
.mrg.
daily CVS update output
Updating src tree: P src/include/sched.h P src/lib/libc/sys/clone.2 P src/sys/dev/ic/ahcisata_core.c P src/sys/dev/ic/bcmgenet.c P src/sys/dev/ic/nslm7x.c P src/sys/dev/ic/nvmereg.h P src/sys/dev/ic/nvmevar.h P src/sys/dev/ic/rtl8169.c P src/sys/dev/ic/tulip.c P src/sys/dev/ic/tulipreg.h P src/sys/dev/wsfb/genfb.c P src/tests/lib/libc/sys/Makefile Updating xsrc tree: P xsrc/external/mit/xf86-video-ati/dist/src/radeon_modes.c P xsrc/external/mit/xf86-video-nouveau/dist/src/nv_driver.c P xsrc/external/mit/xf86-video-openchrome/dist/src/via_fp.c P xsrc/external/mit/xf86-video-savage/dist/src/savage_driver.c P xsrc/external/mit/xf86-video-siliconmotion/dist/src/smi_output.c Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 40676190 Aug 2 03:03 ls-lRA.gz
current USE_SSP=yes build failure
Hi, I have "USE_SSP=yes" in mk.conf and the build is failing with: --- dependall-drivers --- /usr/xsrc/external/mit/xorg-server/dist/hw/xfree86/drivers/modesetting/drmmode_display.c: In function 'drmmode_crtc_gamma_set': /usr/xsrc/external/mit/xorg-server/dist/hw/xfree86/drivers/modesetting/drmmode_display.c:1768:1: error: stack protector not protecting local variables: variable length buffer [-Werror=stack-protector] 1768 | drmmode_crtc_gamma_set(xf86CrtcPtr crtc, uint16_t * red, uint16_t * green, | ^~ Is this to be expected? Am I doing something wrong? The function itself is very simple. Thanks, r.
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2022.08.01.15.16.05 wiz src/include/sched.h,v 1.15 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2022.08.html#2022.08.01.15.16.05
Re: namespace pollution? clone()
The test is fixed now. kre
Re: namespace pollution? clone()
On Mon, Aug 01, 2022 at 05:11:53PM +0200, Thomas Klausner wrote: > I don't understand why we expose __clone() in a public header at all, > but I understand your comments to result in the attached patch. It is used in tests: /tmp/build/2022.08.01.14.34.01-i386/src/tests/lib/libc/sys/t_clone.c:123:16: error: implicit declaration of function '__clone'; did you mean 'close'? [-Werror=implicit-function-declaration] 123 | switch (pid = __clone(clone_func, stack, |^~~ |close Not sure why your test build did not catch it. Martin
Automated report: NetBSD-current/i386 build failure
This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, using sources from CVS date 2022.08.01.14.34.01. An extract from the build.sh output follows: --- .gdbinit --- --- dependall-usr.bin --- --- t_tsan_lock_order_inversion --- --- dependall-lib --- --- dependall-sys --- /tmp/build/2022.08.01.14.34.01-i386/src/tests/lib/libc/sys/t_clone.c:123:16: error: implicit declaration of function '__clone'; did you mean 'close'? [-Werror=implicit-function-declaration] 123 | switch (pid = __clone(clone_func, stack, |^~~ |close --- dependall-sys --- --- dependall-bootxx_lfsv1 --- The following commits were made between the last successful build and the failed build: 2022.08.01.14.19.40 wiz src/include/sched.h,v 1.13 2022.08.01.14.22.32 wiz src/lib/libc/sys/clone.2,v 1.15 2022.08.01.14.34.01 wiz src/include/sched.h,v 1.14 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2022.08.html#2022.08.01.14.34.01
Re: namespace pollution? clone()
On Mon, Aug 01, 2022 at 06:06:19PM +0300, Valeriy E. Ushakov wrote: > On Mon, Aug 01, 2022 at 16:50:14 +0200, Thomas Klausner wrote: > > > On Mon, Aug 01, 2022 at 05:45:23PM +0300, Valeriy E. Ushakov wrote: > > > Shouldn't we expose __clone(2) (the real symbol in the reserved > > > namespace) under _NETBSD_SOURCE and only hide clone(2) weak alias > > > under _GNU_SOURCE? You kinda sidestep some potential issues here in > > > this case b/c __clone is an assembler syscall stub, so there's no C > > > source that implements __close() that has to see the declaration. > > > > I don't understand the problem you see here - please fix it as you > > find appropriate. > > I think we should still expose __clone() under _NETBSD_SOURCE, but > expose clone() only under _GNU_SOURCE. My original reply that > prompted your patch was not very clear about this, but it talked > specifically about clone() (and clone() only). > > Your patch hides both clone() and __clone() under _GNU_SOURCE. You > were not forced to consider this choice b/c __clone() is not > implemented in C, so there's no C code in the tree that needs to see > the __clone() prototype that your patch hides. > > __clone is in the reserved namespace, so no well behaving programs > should be affected by that declaration. I don't understand why we expose __clone() in a public header at all, but I understand your comments to result in the attached patch. Please suggest a comment to put before the __clone() line. Thanks, Thomas Index: sched.h === RCS file: /cvsroot/src/include/sched.h,v retrieving revision 1.14 diff -u -r1.14 sched.h --- sched.h 1 Aug 2022 14:34:01 - 1.14 +++ sched.h 1 Aug 2022 15:10:52 - @@ -73,13 +73,17 @@ /* * Historical functions, not defined in standard - * Linux man page documents these functions as only available when + * Linux man page documents clone() as only available when * _GNU_SOURCE is defined */ pid_t clone(int (*)(void *), void *, int, void *); +#endif /* _GNU_SOURCE */ + +#if defined(_NETBSD_SOURCE) + pid_t __clone(int (*)(void *), void *, int, void *); -#endif /* _GNU_SOURCE */ +#endif /* _NETBSD_SOURCE */ __END_DECLS
Re: namespace pollution? clone()
On Mon, Aug 01, 2022 at 16:50:14 +0200, Thomas Klausner wrote: > On Mon, Aug 01, 2022 at 05:45:23PM +0300, Valeriy E. Ushakov wrote: > > Shouldn't we expose __clone(2) (the real symbol in the reserved > > namespace) under _NETBSD_SOURCE and only hide clone(2) weak alias > > under _GNU_SOURCE? You kinda sidestep some potential issues here in > > this case b/c __clone is an assembler syscall stub, so there's no C > > source that implements __close() that has to see the declaration. > > I don't understand the problem you see here - please fix it as you > find appropriate. I think we should still expose __clone() under _NETBSD_SOURCE, but expose clone() only under _GNU_SOURCE. My original reply that prompted your patch was not very clear about this, but it talked specifically about clone() (and clone() only). Your patch hides both clone() and __clone() under _GNU_SOURCE. You were not forced to consider this choice b/c __clone() is not implemented in C, so there's no C code in the tree that needs to see the __clone() prototype that your patch hides. __clone is in the reserved namespace, so no well behaving programs should be affected by that declaration. -uwe
Re: namespace pollution? clone()
On Mon, Aug 01, 2022 at 05:45:23PM +0300, Valeriy E. Ushakov wrote: > Shouldn't we expose __clone(2) (the real symbol in the reserved > namespace) under _NETBSD_SOURCE and only hide clone(2) weak alias > under _GNU_SOURCE? You kinda sidestep some potential issues here in > this case b/c __clone is an assembler syscall stub, so there's no C > source that implements __close() that has to see the declaration. I don't understand the problem you see here - please fix it as you find appropriate. Thanks, Thomas
Re: namespace pollution? clone()
On Mon, Aug 01, 2022 at 15:57:19 +0200, Thomas Klausner wrote: > On Tue, Jul 26, 2022 at 03:03:54PM +0200, Martin Husemann wrote: > > On Tue, Jul 26, 2022 at 03:46:14PM +0300, Valery Ushakov wrote: > > > On Linux clone(2) is declared only for _GNU_SOURCE, which explains why > > > linux doesn't run into the name clash. I gather we should follow > > > suit, as that's what the apps expect. > > > > Yes, that is the right thing to do here, especially as clone(2) does > > only exist as a portability helper for linux code. > > > > I think we could even pull that change up to -9. > > The attached diff survived a complete amd64-current build. Ok to commit? > Index: sched.h > === > RCS file: /cvsroot/src/include/sched.h,v > retrieving revision 1.12 > diff -u -r1.12 sched.h > --- sched.h 11 Jan 2009 03:04:12 - 1.12 > +++ sched.h 1 Aug 2022 13:57:06 - > @@ -59,20 +59,26 @@ > #define sched_yield __libc_thr_yield > #endif /* __LIBPTHREAD_SOURCE__ */ > > -#if defined(_NETBSD_SOURCE) > - > __BEGIN_DECLS > > +#if defined(_NETBSD_SOURCE) > + > /* Process affinity functions (not portable) */ > int sched_getaffinity_np(pid_t, size_t, cpuset_t *); > int sched_setaffinity_np(pid_t, size_t, cpuset_t *); > > +#endif /* _NETBSD_SOURCE */ > + > +#if defined(_GNU_SOURCE) > + > /* Historical functions, not defined in standard */ > +/* Linux man page documents these functions as only available when > + * _GNU_SOURCE is defined */ > pid_t clone(int (*)(void *), void *, int, void *); > pid_t__clone(int (*)(void *), void *, int, void *); > > -__END_DECLS > +#endif /* _GNU_SOURCE */ > > -#endif /* _NETBSD_SOURCE */ > +__END_DECLS > > #endif /* _SCHED_H_ */ Shouldn't we expose __clone(2) (the real symbol in the reserved namespace) under _NETBSD_SOURCE and only hide clone(2) weak alias under _GNU_SOURCE? You kinda sidestep some potential issues here in this case b/c __clone is an assembler syscall stub, so there's no C source that implements __close() that has to see the declaration. -uwe
Re: namespace pollution? clone()
On 2022/08/01 23:22, Thomas Klausner wrote: On Mon, Aug 01, 2022 at 11:20:11PM +0900, Rin Okuyama wrote: On 2022/08/01 23:13, Martin Husemann wrote: On Mon, Aug 01, 2022 at 03:57:19PM +0200, Thomas Klausner wrote: The attached diff survived a complete amd64-current build. Ok to commit? Looks good to me. Can you please mention _GNU_SOURCE in clone(2)? Thanks for the reminder - done! Thanks! rin
Re: namespace pollution? clone()
On Mon, Aug 01, 2022 at 07:32:26AM -0700, Jason Thorpe wrote: > > > On Aug 1, 2022, at 7:22 AM, Thomas Klausner wrote: > > > > On Mon, Aug 01, 2022 at 11:20:11PM +0900, Rin Okuyama wrote: > >> On 2022/08/01 23:13, Martin Husemann wrote: > >>> On Mon, Aug 01, 2022 at 03:57:19PM +0200, Thomas Klausner wrote: > The attached diff survived a complete amd64-current build. Ok to commit? > >>> > >>> Looks good to me. > >> > >> Can you please mention _GNU_SOURCE in clone(2)? > > > > Thanks for the reminder - done! > > Please also fix the comment style to conform to KNF. Done. Thomas
Re: namespace pollution? clone()
> On Aug 1, 2022, at 7:22 AM, Thomas Klausner wrote: > > On Mon, Aug 01, 2022 at 11:20:11PM +0900, Rin Okuyama wrote: >> On 2022/08/01 23:13, Martin Husemann wrote: >>> On Mon, Aug 01, 2022 at 03:57:19PM +0200, Thomas Klausner wrote: The attached diff survived a complete amd64-current build. Ok to commit? >>> >>> Looks good to me. >> >> Can you please mention _GNU_SOURCE in clone(2)? > > Thanks for the reminder - done! Please also fix the comment style to conform to KNF. -- thorpej
Re: namespace pollution? clone()
On Mon, Aug 01, 2022 at 11:20:11PM +0900, Rin Okuyama wrote: > On 2022/08/01 23:13, Martin Husemann wrote: > > On Mon, Aug 01, 2022 at 03:57:19PM +0200, Thomas Klausner wrote: > > > The attached diff survived a complete amd64-current build. Ok to commit? > > > > Looks good to me. > > Can you please mention _GNU_SOURCE in clone(2)? Thanks for the reminder - done! Thomas
Re: namespace pollution? clone()
On 2022/08/01 23:13, Martin Husemann wrote: On Mon, Aug 01, 2022 at 03:57:19PM +0200, Thomas Klausner wrote: The attached diff survived a complete amd64-current build. Ok to commit? Looks good to me. Can you please mention _GNU_SOURCE in clone(2)? Thanks, rin
Re: namespace pollution? clone()
On Mon, Aug 01, 2022 at 03:57:19PM +0200, Thomas Klausner wrote: > The attached diff survived a complete amd64-current build. Ok to commit? Looks good to me. Martin
Re: namespace pollution? clone()
On Tue, Jul 26, 2022 at 03:03:54PM +0200, Martin Husemann wrote: > On Tue, Jul 26, 2022 at 03:46:14PM +0300, Valery Ushakov wrote: > > On Linux clone(2) is declared only for _GNU_SOURCE, which explains why > > linux doesn't run into the name clash. I gather we should follow > > suit, as that's what the apps expect. > > Yes, that is the right thing to do here, especially as clone(2) does > only exist as a portability helper for linux code. > > I think we could even pull that change up to -9. The attached diff survived a complete amd64-current build. Ok to commit? Thomas Index: sched.h === RCS file: /cvsroot/src/include/sched.h,v retrieving revision 1.12 diff -u -r1.12 sched.h --- sched.h 11 Jan 2009 03:04:12 - 1.12 +++ sched.h 1 Aug 2022 13:57:06 - @@ -59,20 +59,26 @@ #define sched_yield__libc_thr_yield #endif /* __LIBPTHREAD_SOURCE__ */ -#if defined(_NETBSD_SOURCE) - __BEGIN_DECLS +#if defined(_NETBSD_SOURCE) + /* Process affinity functions (not portable) */ intsched_getaffinity_np(pid_t, size_t, cpuset_t *); intsched_setaffinity_np(pid_t, size_t, cpuset_t *); +#endif /* _NETBSD_SOURCE */ + +#if defined(_GNU_SOURCE) + /* Historical functions, not defined in standard */ +/* Linux man page documents these functions as only available when + * _GNU_SOURCE is defined */ pid_t clone(int (*)(void *), void *, int, void *); pid_t __clone(int (*)(void *), void *, int, void *); -__END_DECLS +#endif /* _GNU_SOURCE */ -#endif /* _NETBSD_SOURCE */ +__END_DECLS #endif /* _SCHED_H_ */
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2022.08.01.10.30.28 kre src/sys/dev/ic/tulip.c,v 1.208 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2022.08.html#2022.08.01.10.30.28
Automated report: NetBSD-current/i386 build failure
This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, using sources from CVS date 2022.08.01.08.09.30. An extract from the build.sh output follows: mv -f kern_uipc_socket_50.d.tmp kern_uipc_socket_50.d --- kern-XEN3PAE_DOMU --- --- kobj_machdep.o --- --- kern-XEN3PAE_DOM0 --- --- tulip.d --- /tmp/build/2022.08.01.08.09.30-i386/src/sys/dev/ic/tulip.c:41:10: fatal error: bpfilter.h: No such file or directory 41 | #include "bpfilter.h" | ^~~~ compilation terminated. --- kern-XEN3PAE_DOMU --- # compile XEN3PAE_DOMU/kobj_machdep.o The following commits were made between the last successful build and the failed build: 2022.08.01.07.37.18 mlelstv src/sys/dev/ic/ahcisata_core.c,v 1.107 2022.08.01.07.37.18 mlelstv src/sys/dev/ic/bcmgenet.c,v 1.13 2022.08.01.07.37.18 mlelstv src/sys/dev/ic/nvmevar.h,v 1.26 2022.08.01.07.37.18 mlelstv src/sys/dev/ic/rtl8169.c,v 1.174 2022.08.01.07.37.18 mlelstv src/sys/dev/ic/tulip.c,v 1.207 2022.08.01.07.37.18 mlelstv src/sys/dev/ic/tulipreg.h,v 1.43 2022.08.01.08.09.30 mlelstv src/sys/dev/ic/nvmevar.h,v 1.27 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2022.08.html#2022.08.01.08.09.30
