Re: git: 5e04571cf3cf - main - sys/bitset.h: reduce visibility of BIT_* macros

Am 07.12.21 um 01:50 schrieb Mark Millard:
> 
> 
> On 2021-Dec-6, at 14:48, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> 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 "malloc"
>>> 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 "malloc"
>>  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:
> 
> work/gcc-11.2.0/gcc/jit/{libgccjit,jit-recording,jit-playback}.c
> 
> builds is what poisons malloc in each case (and poisons more):
> 
> #include "config.h"
> #include "system.h"
> #include "coretypes.h"
> #include "timevar.h"
> #include "typed-splay-tree.h"
> #include "cppbuiltin.h"
> #include <pthread.h>
> 
> 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.
> 
> 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