This is the mail archive of the
mailing list for the Cygwin project.
Re: 1.7.25, Windows 7: dumper doesn't generate core file
- From: "Sam Liapis at constrainttec dot com" <Sam dot Liapis at constrainttec dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 19 Mar 2014 16:54:36 +1100
- Subject: Re: 1.7.25, Windows 7: dumper doesn't generate core file
- Authentication-results: sourceware.org; auth=none
- References: <53277ECE dot 5030003 at constrainttec dot com> <53278073 dot 4030909 at constrainttec dot com> <20140318105218 dot GD28387 at calimero dot vinschen dot de>
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:
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
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
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.
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.
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/
/ 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,
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple