Date: Tue, 7 Dec 2021 18:49:53 +0100 From: Stefan Esser <se@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: Konstantin Belousov <kib@freebsd.org>, Mark Johnston <markj@FreeBSD.org>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: git: 5e04571cf3cf - main - sys/bitset.h: reduce visibility of BIT_* macros Message-ID: <4808c5fb-4d54-ecec-9796-e68cbc07e06d@freebsd.org> In-Reply-To: <A4D92600-7DD1-47E8-A741-A3DA62BAAFEE@yahoo.com> References: <BB117F7A-08DF-4F42-BB34-453BD0BA417A@yahoo.com> <B395690A-AA37-47AC-A729-ABDC73821732@yahoo.com> <A4D92600-7DD1-47E8-A741-A3DA62BAAFEE@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------UmoqKbeewJtpGFTMvVwxXdNV
Content-Type: multipart/mixed; boundary="------------KlzVuNV6daWUG0kuODVQRwaZ";
protected-headers="v1"
From: Stefan Esser <se@freebsd.org>
To: Mark Millard <marklmi@yahoo.com>
Cc: Konstantin Belousov <kib@freebsd.org>, Mark Johnston <markj@FreeBSD.org>,
freebsd-current <freebsd-current@freebsd.org>
Message-ID: <4808c5fb-4d54-ecec-9796-e68cbc07e06d@freebsd.org>
Subject: Re: git: 5e04571cf3cf - main - sys/bitset.h: reduce visibility of
BIT_* macros
References: <BB117F7A-08DF-4F42-BB34-453BD0BA417A@yahoo.com>
<B395690A-AA37-47AC-A729-ABDC73821732@yahoo.com>
<A4D92600-7DD1-47E8-A741-A3DA62BAAFEE@yahoo.com>
In-Reply-To: <A4D92600-7DD1-47E8-A741-A3DA62BAAFEE@yahoo.com>
--------------KlzVuNV6daWUG0kuODVQRwaZ
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Am 07.12.21 um 01:50 schrieb Mark Millard:
>=20
>=20
> On 2021-Dec-6, at 14:48, Mark Millard <marklmi@yahoo.com> wrote:
>=20
>> On 2021-Dec-6, at 14:19, Mark Millard <marklmi@yahoo.com> wrote:
>>
>>> This broke building lang/gcc11 so may be a exp run is appropriate:
>>>
>>> In file included from /usr/include/sys/cpuset.h:39,
>>> from /usr/include/sched.h:36,
>>> from /usr/include/pthread.h:48,
>>> from /wrkdirs/usr/ports/lang/gcc11/work/gcc-11.2.0/gcc=
/jit/libgccjit.c:27:
>>> /usr/include/sys/bitset.h:314:36: error: attempt to use poisoned "mal=
loc"
>>> 314 | #define __BITSET_ALLOC(_s, mt, mf) malloc(__BITSET_SIZE((_s)), =
mt, (mf))
>>> | ^
[...]
>> Just like the poudriere-devel based build on aarch64,
>> amd64's poudriere-devel based build got:
>>
>> In file included from /usr/include/sys/cpuset.h:39,
>> from /usr/include/sched.h:36,
>> from /usr/include/pthread.h:48,
>> from /wrkdirs/usr/ports/lang/gcc11/work/gcc-11.2.0/gcc=
/jit/libgccjit.c:27:
>> /usr/include/sys/bitset.h:314:36: error: attempt to use poisoned "mall=
oc"
>> 314 | #define __BITSET_ALLOC(_s, mt, mf) malloc(__BITSET_SIZE((_s)), =
mt, (mf))
>> | ^
[...]
> This happens from the sequence below, where system.h use in
> the:
>=20
> work/gcc-11.2.0/gcc/jit/{libgccjit,jit-recording,jit-playback}.c
>=20
> builds is what poisons malloc in each case (and poisons more):
>=20
> #include "config.h"
> #include "system.h"
> #include "coretypes.h"
> #include "timevar.h"
> #include "typed-splay-tree.h"
> #include "cppbuiltin.h"
> #include <pthread.h>
>=20
> After the poison-point, new macro definitions can not
> reference malloc (and such) --nor can normal code. But
> macros defined prior to the poison-point can contain
> malloc (and such) and the use of such macros after
> the poison point is okay.
>=20
> So, if pthread.h is to define a macro referencing
> malloc (say), then it needs to be included before
> system.h is included in the way that things are set up
> in this code.
Hi Mark,
sorry for (indirectly) causing the breakage ...
The problem seems to be the inclusion of extra functionality
in sched.h, that is required by a number of programs that use
autoconfigure. They probe for one detail of sched.h and then
try to use functionality that up to the commit you are referencing
had to be hidden (made conditional on _WITH_CPUT_SET_T).
The line that contains the malloc() is in a macro definition and
AFAIU the situation there is no actual use of __BITSET_ALLOC in
the gcc code.
In fact, I could not find a single use of BITSEC_ALLOC in userland
code. Therefore, the line that contains the malloc could be made
conditional on _KERNEL being defined.
> I've only tried to build lang/gcc11 (only as supplied
> by the port). There could be more failure points for
> the lang/gcc11 build that were skipped.
At least the other gcc ports. I do not think that there are many
other ports that do not accept the definition of a macro using
malloc() in the way the poisoning in gcc does.
> It seems likely that multiple lang/gcc* would have
> such issues but I normally only build the lang/gcc11
> one at this point.
I have not tested the other ports, but I do assume the same.
I'll try to build the world with BITSET_ALLOC conditional on
some macro that is not defined in the gcc build.
Regards, STefan
--------------KlzVuNV6daWUG0kuODVQRwaZ--
--------------UmoqKbeewJtpGFTMvVwxXdNV
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"
-----BEGIN PGP SIGNATURE-----
wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmGvnsEFAwAAAAAACgkQR+u171r99UQU
zwgAyCsgFR4/L4qQzhwbNwUsXG0ALz1ht5NGMDpLP7w8VN6VKq9JXdiOtBFLF7ZZybZP2H0bUcMf
KD8FkohxeWPASsYos4PLKjGFBSufmD71SsYfcUfXXdbnIyhza/WVbjKknnu8c3I5gpsQ1VUnkTxQ
C8w7NlEsJLHL5EbWoVSYegduSJKgJjMIzQ+VMIwX510Wfht2IKsXADemhUN99nhy+MM1UvSYsgmB
ZoZZ1se1SzjrP7mjP7CINAPe23ZUlYiV8i02ga/SEqeF6niYnlUSyS2QuDDIiiwCM+H/8jLkf9gR
Z7LA0QePsrntnFeWSclxvhO9IOjWIliNWmoj2F72cQ==
=tSZj
-----END PGP SIGNATURE-----
--------------UmoqKbeewJtpGFTMvVwxXdNV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4808c5fb-4d54-ecec-9796-e68cbc07e06d>