X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=kpqFyTdq3C7u4E/L2rQVYEDP+kJG75C3gR1snrFnXRO
	CXKu0iUVqgzJ8c2v7L8dDFP9y/lO+YVURofESEhhCeK24BAKIL68knnT7C+P74rb
	4G25KY8PZTTdsXHf5aS72O2nsyDxNiOjY5FomRX9qRPm/aITZxoOBpA8DkU0oKhs
	=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 s=default; bh=gkWAPmutxmy87qjEKVUrtSPP2cE=; b=Mudj1xZgm0bks9XBi
	yz910/hkX0UHHdcLoqWmdgxsnB5Qy/D3NLKveIJnPf5qAT5X8CtulTWRsqSF7eOJ
	ci264rdg5QgYaAx5gGLwcCpgLqhQ36HcBmm7HJtYu0qkpVzUURh6WpDkQ7Qq3uw1
	++9L6+dY9/GDQF+hYGLpyfp0kg=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO: red.contecint.com.au
Message-ID: <5329311C.1060604@constrainttec.com>
Date: Wed, 19 Mar 2014 16:54:36 +1100
From: "Sam Liapis AT constrainttec DOT com" <Sam DOT Liapis AT constrainttec DOT com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: 1.7.25, Windows 7: dumper doesn't generate core file
References: <53277ECE DOT 5030003 AT constrainttec DOT com> <53278073 DOT 4030909 AT constrainttec DOT com> <20140318105218 DOT GD28387 AT calimero DOT vinschen DOT de>
In-Reply-To: <20140318105218.GD28387@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes


You're write Corrina I tried you're suggested test and it clearly proved 
ALL file sections are loaded.

I found a great memory visualiser tool VMMap here: 
http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx

I then re-run my original test and used VMMap to compare all DLL section 
addresses with dumper's diagnostic trace.

It turns out around half of the DLL section addresses didn't line-up 
with the sensible VMAs shown in VMMap's display.

For example the problematic *sechost.dll *file presented with the 
following differences:

DUMPER OUTPUT:
...
got debug event 6
excluding section: name=.text   base=*0x2b21000* size=00012c1b  <== NOTE 
the way out of range section VMA.
added module *0x75510000* C:\Windows\SysWOW64\sechost.dll
...

VMMap OUTPUT:
...
Base Address *0x75510000*
.text Address *0x75511000* <== sits nicely above of base VMA as do all 
the other DLL's sections.
.text Size 76K
...

This occurred for a number of other DLLs where the .text section 
addresses differed whereby dumper's was invalid.

At this stage I don't have time to dig into binutils source which 
appears to be providing the erroneous section VMAs.

I have to think about how I might present this back to the binutils 
mailing list given it's in a Windows environment.

Regards,
Sam


On 18/03/14 21:52, Corinna Vinschen wrote:
> On Mar 18 10:08, Sam Liapis at constrainttec dot com wrote:
>> Thanks Christopher - I've since posted to binutils mailing list and
>> had a helpful response.
>>
>> Original post:http://lists.gnu.org/archive/html/bug-binutils/2014-03/msg00076.html
>>       Response:http://lists.gnu.org/archive/html/bug-binutils/2014-03/msg00086.html
>>
>> As you noted and is also clearly implied in feedback memory sections do not overlap.
>>
>> It's verified by examining flags for allegedly overlapping sections using objdump utility.
>> As stated in the response, flags indicate that not all sections may be residing in memory.
>>
>> ===========================================================================================================
>> On Fri, Mar 14, 2014 at 11:15:38AM +1100, Sam address at hidden wrote:
>>> /  $ objdump -h airdac_.exe/
>>> /  airdac_.exe:     file format pei-i386/
>>> /  Sections:/
>>> /  Idx Name          Size      VMA       LMA       File off  Algn/
>>> /    0 .text         008d8980  00401000  00401000  00000400  2**4/
>>> /                    CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA/
>>> /    .../
>>> /    7 .debug_info   151e2063  028ca000  028ca000  024b3000  2**0 <==/  /VMA and SIZE match-up with trace above/
>>> /                    CONTENTS, READONLY, DEBUGGING/
>> As you can see from the flags above, .debug_info is not ALLOC, LOAD.
>> This means the section is not loaded into memory and the VMA is
>> irrelevant.  Another DLL could well occupy this space, because
>> airdac_.exe does not use that memory.
> Alan got that wrong.  This is Windows, so not everything which looks
> logical is working logically.
>
> On Windows, the loader maps the *entire* file into memory, even the
> NOLOAD sections.  That's why stripping executables and DLLs is always
> a good idea.
>
> You can easily see for yourself:
>
> - Compile a short test application which does nothing but calling
>    getchar() to wait for user input.  Compile it with the -g option.
>
> - Check the memory layout of the executable using `objdump -h'.
>
> - Start the application, let it run, and switch to another Cygwin window.
>
> - Check the pid of the application with ps and call `less /proc/$PID/maps'.
>
> - Observe the memory layout of the executable.
>
> But still, since the sections are taken by the executable, there's
> no way that any other DLL can use the same memory addresses so I don't
> see a way that sections overlap.  However, a DLL could have a *default*
> load address which overlaps with an existing section in memory.  In
> that case the DLL gets rebased to another address in memory, though,
> so there's still no overlap.
>
>> Question is should this section test also check if it's resident in
>> memory i.e. code mod as follows?
>>
>>       ...
>>       77   if ((sect->flags & (SEC_CODE | SEC_DEBUGGING)) &&
>>       78       (sect->flags & (SEC_LOAD | SEC_ALLOC)) &&   <== CODE ADDITION
>>       79       sect->vma && bfd_get_section_size (sect))
>>       ...
> Would you mind to show code changes in the form of `cvs diff -up' or
> simple `diff -up' code snippets?  It makes things a bit more clear,
> usually.
>
>
> Thanks,
> Corinna

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple