As a disclaimer I'm new to binutils, memory mapping and Cygwin covered
in this post.
I'm not sure if I first need to submit a bug report to
http://sourceware.org/bugzilla/ ?
(I didn't find any "How to submit a bug FAQ" anywhere on the binutils
home page)
Let me also apologise up-front for the lengthy post as I couldn't
condense it further.
My brief was to resolve an issue with a Cygwin 'dumper' utility not
producing a core.
Dumper makes use of binutils to achieve it's purpose hence the reason
for this post.
(i.e. postings on Cygwin's mailing list led to the suggestion I make
this post here)
With that I'll proceed with outlining the journey including my findings
so far.
For a given process dumper works through sections of memory to determine
which
are to be excluded from the core dump i.e those with CODE or DEBUGGING
sections.
I'll begin with the error message given by dumper when run in verbose mode:
(Note objects in question are "airdac_.exe", "sechost.dll" and
"napinsp.dll")
...
$ dumper -d "C:\Program Files (x86)\Airdac 12.6.22\airdac_.exe" 3356
dumping process #3356 to airdac_.exe.core
got debug event 3
excluding section: name= .text base=0x401000
size=008d8980
excluding section: name= .debug_aranges base=0x2699000 size=00230850
excluding section: name= .debug_info base=0x28ca000
size=151e2063 <== NOTE THIS EXE EXCLUDED SECTION
excluding section: name= .debug_abbrev base=0x17aad000 size=0023f840
...
added module 0x400000 C:\Program Files (x86)\Airdac 12.6.22\airdac_.exe
...
got debug event 6
excluding section: name= .text base=0x2b21000
size=00012c1b <== DLL SEC OVERLAPS with EXCLUSION ABOVE?
added module 0x768d0000 C:\Windows\SysWOW64\sechost.dll
...
got debug event 6
excluding section: name= .text base=0x3321000
size=0000b03c <== DLL SEC OVERLAPS with EXCLUSION ABOVE?
added module 0x73c80000 C:\Windows\system32\napinsp.dll
...
I then ran 'objdump' against the EXE and DLLs named above by way of
comparison:
$ objdump -h airdac_.exe
airpac_.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
...
$ objdump -h "C:\Windows\SysWOW64\sechost.dll"
C:\Windows\SysWOW64\sechost.dll: file format pei-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00012c1b 02b21000 02b21000 00000600 2**2
<== VMA and SIZE match-up with trace above
CONTENTS, ALLOC, LOAD, READONLY, CODE
...
$ objdump -h "C:\Windows\system32\napinsp.dll"
C:\Windows\system32\napinsp.dll: file format pei-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0000b03c 03321000 03321000 00000400 2**2 <==
VMA and SIZE match-up with trace above
CONTENTS, ALLOC, LOAD, READONLY, CODE
...
Herein lies the issue where both dumper and objdump identify sections
which overlap by
address for a given process. This leads me to the main question for this
post:
SHOULD SECTIONS BELONGING TO THE SAME PROCESS(plus it's DLLs) EVER HAVE
OVERLAPPING VMAs?
Dumper logic suggests it shouldn't occur and fails hence an answer will
determine the fix.
Not sure there's value in providing the following information but
nonetheless here it is.
By way of context I'll give a very brief overview on how dumper
determines which sections
to exclude. The two source files referred to in this post (i.e.
dumper.cc & parse_pe.cc)
can be accessed via these two links:
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/utils/dumper.cc?cvsroot=src
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/utils/parse_pe.cc?cvsroot=src
Inside dumper.cc there's a while loop acting on debug events for a given
process.
For PROCESS & DLL DEBUG EVENTs it calls add_module(...) for subsequent
processing.
dumper::collect_process_information()
{
...
while (1)
{
if (!WaitForDebugEvent (¤t_event, 20000))
...
switch (current_event.dwDebugEventCode)
{
...
case CREATE_PROCESS_DEBUG_EVENT:
add_module (current_event.u.CreateProcessInfo.lpBaseOfImage);
...
break;
...
case LOAD_DLL_DEBUG_EVENT:
add_module (current_event.u.LoadDll.lpBaseOfDll);
...
break;
...
}
...
}
}
...
dumper::add_module (LPVOID base_address)
{
...
parse_pe (module_name, excl_list);
...
}
Inside of parse_pe.cc is where the binutil activity occurs. The relevant
code which
surveys process mem sections to find exclusions & generate trace shown
above follows:
...
parse_pe (const char *file_name, exclusion * excl_list)
{
...
bfd *abfd = bfd_openr (file_name, "pei-i386");
...
bfd_check_format (abfd, bfd_object);
bfd_map_over_sections (abfd, &select_data_section, (PTR) excl_list);
excl_list->sort_and_check ();
bfd_close (abfd);
return 1;
}
...
select_data_section (bfd * abfd, asection * sect, PTR obj)
{
exclusion *excl_list = (exclusion *) obj;
if ((sect->flags & (SEC_CODE | SEC_DEBUGGING)) &&
sect->vma && bfd_get_section_size (sect))
{
excl_list->add ((LPBYTE) sect->vma, (SIZE_T) bfd_get_section_size
(sect));
deb_printf ("excluding section: name=%20s base=%p size=%08lx\n",
sect->name, sect->vma, bfd_get_section_size (sect));
}
}
...
As noted I'm new to the binutils paddock so please go easy on this
little sheep.
I appreciate any insight and advice anyone can provide to this issue.
Thanks,
Sam
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
