Re: Should mem sections have overlapping addresses?

[Sam address@hidden]

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 (&current_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