DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=xzcFg/LTguyy1Ss6gnvmY7DsBv66ykY2aVOZ+9HFGxSbrfnVuoygb
	3mijo9+r2+q7nK1mB61pQtZtEWjiDhHw6pE0wVAFAvhiJoBrR7FnAbYJvtVwFAUZ
	0P7ApLIrmGbARKreG3mmta2FZ/DbDKiDAYlDIqcvkRQC1Qvsggc0CQ=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Tue, 18 Mar 2014 11:52:18 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: 1.7.25, Windows 7: dumper doesn't generate core file
Message-ID: <20140318105218.GD28387@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <53277ECE DOT 5030003 AT constrainttec DOT com> <53278073 DOT 4030909 AT constrainttec DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="Pk6IbRAofICFmK5e"
Content-Disposition: inline
In-Reply-To: <53278073.4030909@constrainttec.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

--Pk6IbRAofICFmK5e
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> 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
>=20
> As you noted and is also clearly implied in feedback memory sections
> do not overlap.
>=20
> 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.
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
> 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 <=3D=
=3D/  /VMA and SIZE match-up with trace above/
> >/                    CONTENTS, READONLY, DEBUGGING/
>=20
> 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?
>=20
>      ...
>      77   if ((sect->flags & (SEC_CODE | SEC_DEBUGGING)) &&
>      78       (sect->flags & (SEC_LOAD | SEC_ALLOC)) &&
> <=3D=3D 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

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--Pk6IbRAofICFmK5e
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJTKCVhAAoJEPU2Bp2uRE+gtkIP/21A9lcb6D7kanL/P+6hpUIL
SjeENOc68cauwZ90Yxm+jXTkcb9p5dK1XA72N+7zLgmJsWbscBY7f6DQcFxDYitn
BQD2GDSZfaBOZDLwCCSYy0+U5IMPlaSrCFfX2fFYbT/i709OoCXeDqlY+zeL2FmR
H8DKPZJTRDS4Wu13P4bnjrjlwVHGfAV8y+gQbHYkkWQ0uuo/T7oLDelq6oBlrc65
jpFN9FWF/iJVLTKTBNG4Pp9wXsOyC6prSr3NAxnv6f7EgT5crFJgZ+sb27LYUxiG
UNV+6cC1bI4zkI1bc17ii/bglGJjKveIn775bmhedzge+E4OMHiJ459F1Wl4MnaR
pN0IUPjLxo4eb+mLVt4U4VBvpt7fK7Rp4g6H0MlzLhZ2zPkrmC//jx5LOC+JlxPU
8AFlZgrZX/Q6c5HHqKox9fiF4LZDFsygKOr897BMxN4sDN+skCcFViFmfALFsyfz
VaOdsZLkFqSIEiH7bLekHwSgzxGUcZvgW4x+0EvR6t8/Xo2hdbf26O7IfplhOsS3
TjwShCbbEewOYgSrxslA1SZhBOPSC+90mTNFJrUKZSGB6bm5n0MH9+brq4LzFwEP
R/MgCOHuhEiHq0MiI3l+EP2Zh+RN/U8EnwdgALQzsjaC1jOYaEUAgAL17bOKwhEU
tN+ZVTx4JYgWvGBX3wji
=S5lT
-----END PGP SIGNATURE-----

--Pk6IbRAofICFmK5e--