1.7.25, Windows 7: dumper doesn't generate core file

[Sam Liapis@constrainttec.com]

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