Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Mar 2010 21:42:12 -0500
From:      Nathan Whitehorn <nwhitehorn@freebsd.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Review/testing request: changing the detection of data_addr/text_addr
Message-ID:  <4BAACD84.5040100@freebsd.org>
In-Reply-To: <201003241642.00246.jhb@freebsd.org>
References:  <4BAA6813.7060604@freebsd.org> <201003241642.00246.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
> On Wednesday 24 March 2010 3:29:23 pm Nathan Whitehorn wrote:
>   
>> We currently detect the offical "text" and "data" addresses for ELF 
>> files in kern/imgact_elf.c by the heuristic of calling whichever section 
>> contains the executable's entry point the text section and everything 
>> else data. In general, both this concept and the very few things that 
>> use them are obsolete and rare. The data addresses are, however, used in 
>> obreak() to find the current break. On powerpc64, this logic fails, 
>> because the entry point points to a function descriptor in the data 
>> section, causing sbrk() to fail, which in turn breaks profiling.
>>
>> The patch at http://people.freebsd.org/~nwhitehorn/textseg.diff changes 
>> this algorithm to make the official text area be the largest executable 
>> segment, and all others data. The patch has been tested on sparc64, 
>> amd64, powerpc, and (of course) powerpc64, with no evident bad effects.
>>     
>
> My only comment is that I would keep the existing language about obreak() as 
> it describes multiple data segments, etc.  Instead, I would just use the first 
> sentence of your new comment to replace the first paragraph in the old 
> comment.
>   
That's a good point. I've updated the patch with the new comment. Thanks 
for taking a look! If no one objects, I'll commit both of these patches 
tomorrow.
-Nathan




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