Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Sep 2010 19:25:05 +0300
From:      Andriy Gapon <avg@freebsd.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r212647 - head/sys/sys
Message-ID:  <4C90F361.4090106@freebsd.org>
In-Reply-To: <201009151157.24735.jhb@freebsd.org>
References:  <201009151002.o8FA2kvO029237@svn.freebsd.org> <201009151157.24735.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
on 15/09/2010 18:57 John Baldwin said the following:
> On Wednesday, September 15, 2010 6:02:46 am Andriy Gapon wrote:
>> Author: avg
>> Date: Wed Sep 15 10:02:46 2010
>> New Revision: 212647
>> URL: http://svn.freebsd.org/changeset/base/212647
>>
>> Log:
>>   sys/pcpu.h: remove a workaround for a fixed ld bug
>>   
>>   The workaround was incorrectly documented as having something to do with
>>   set_pcpu section's progbits, but in fact it was for incorrect placement
>>   of __start_set_pcpu because of the bug in ld.
>>   The bug was fixed in r210245, see commit message for details.
>>   
>>   A side-effect of the workaround was that a zero-size set_pcpu section was
>>   produced for modules, source code of which included pcpu.h but didn't
>>   actually define any dynamic per-cpu variables.
>>   This commit should remove the side-effect.
>>   
>>   The same workaround is present sys/net/vnet.h, has an analogous side-effect
>>   and can be removed as well.
>>   
>>   An UPDATING entry that warns about a need for recent ld is following.
>>   
>>   MFC after:	1 month
>>
>> Modified:
>>   head/sys/sys/pcpu.h
>>
>> Modified: head/sys/sys/pcpu.h
>> ==============================================================================
>> --- head/sys/sys/pcpu.h	Wed Sep 15 09:48:18 2010	(r212646)
>> +++ head/sys/sys/pcpu.h	Wed Sep 15 10:02:46 2010	(r212647)
>> @@ -44,24 +44,10 @@
>>  
>>  /*
>>   * Define a set for pcpu data.
>> - * 
>> - * We don't use SET_DECLARE because it defines the set as 'a' when we
>> - * want 'aw'.  gcc considers uninitialized data in a separate section
>> - * writable, and there is no generic zero initializer that works for
>> - * structs and scalars.
>>   */
>>  extern uintptr_t *__start_set_pcpu;
>>  extern uintptr_t *__stop_set_pcpu;
> 
> Given that you removed this comment, can you now use SET_DECLARE() here?

No, why, for what do you want it to use?

-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C90F361.4090106>