From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 27 19:08:22 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF86F1065670 for ; Fri, 27 Nov 2009 19:08:22 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-yw0-f204.google.com (mail-yw0-f204.google.com [209.85.211.204]) by mx1.freebsd.org (Postfix) with ESMTP id 6281D8FC1F for ; Fri, 27 Nov 2009 19:08:22 +0000 (UTC) Received: by ywh42 with SMTP id 42so1610516ywh.28 for ; Fri, 27 Nov 2009 11:08:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=8LdnOKB/Qibq9mnHSCMsVHnIFg+kmWTq312MKXIlUvU=; b=ago/ds/oDEJJByW1iwvVHd5zdabeeyYlu+KGAKQJZ56e3itU2MEf9+f0Z8je93hq3G RgY1c6NwSmJElMQNrDEH0OYhsYWCDcNPOyWabwKKIGE0VC0nDz0U3zlTgVO3vHXb/QKi V0AtTtLOq+21tYcpWUIOizOjqmRVJvSnBirpI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; b=uomaWDcGj5LA01xoTBaQgqNldFLgwGE85vJXYsDoaGqw5q1bO1+mjBS4DWsl8m4ka8 0lt1vjNWWTo7gHYWnANs63vBE8EoXH5DRDT9XddqhCztNCuO7SDUMvwnynglNw3maHuQ lDwKb2BNUF/se56WhcKCQQhygU3NfTEtPDk6o= Received: by 10.150.7.6 with SMTP id 6mr2293182ybg.261.1259348900823; Fri, 27 Nov 2009 11:08:20 -0800 (PST) Received: from doormat.home (c-98-207-40-172.hsd1.ca.comcast.net [98.207.40.172]) by mx.google.com with ESMTPS id 6sm692950ywd.37.2009.11.27.11.08.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Nov 2009 11:08:19 -0800 (PST) Date: Fri, 27 Nov 2009 11:08:16 -0800 From: Navdeep Parhar To: "Bjoern A. Zeeb" Message-ID: <20091127190815.GA15536@doormat.home> Mail-Followup-To: "Bjoern A. Zeeb" , freebsd-hackers@freebsd.org References: <20091127084843.V37440@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091127084843.V37440@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: zero size set_pcpu linker sets X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 19:08:22 -0000 On Fri, Nov 27, 2009 at 08:51:41AM +0000, Bjoern A. Zeeb wrote: > On Tue, 24 Nov 2009, Navdeep Parhar wrote: > > Hi, > > >objdump -h shows that most, but not all, KLDs on amd64 have a "set_pcpu" > >section of size 0. Why? What is the difference between having a 0 > >sized set_pcpu vs. not having it at all? > > > >The kernel linker considers the alignment requirements of these empty > >sections and advances mapsize/mapbase. This bothers my kgdb (which is > >slightly modified to deal with amd64 KLDs). > > So what's your real problem? > I'm trying to read a KLD's globals etc. from its .bss and .data from within kgdb. It has a problem on amd64 that was discussed a long time back: http://lists.freebsd.org/pipermail/freebsd-hackers/2008-September/026014.html The workaround I was using failed after the appearance of set_pcpu, and that made me look at the object file and the kernel linker code. I think there are two minor problems: a) There is an empty set_pcpu in the KLD when it shouldn't be there. b) The kernel linker doesn't ignore this section even though it's empty. It ends up advancing its location calculations because of the way it considers alignment requirements, even for empty sections. > > >I'm using the patch shown here as a stopgap measure. I think the correct > >fix is to not have these empty sections in the KLD to begin with. > > Right. The problem here is a bug with ld and linker sets and size and > aligment calculations the the elf section is started when not all of > this is known correctly and it's not fixed later. This came up with > that "netisr" bug where we had seen the misalignment of the dpcpu set. Yes, I remember that bug, and some of the changes that went in to fix it. Do you know why this empty set_pcpu shows up in most, but not all KLDs? I was hoping we could remove it from all the ones that don't really have any PCPU data. Regards, Navdeep