From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6314 invoked by alias); 16 Jan 2003 16:19:26 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 6301 invoked from network); 16 Jan 2003 16:19:23 -0000 Received: from unknown (HELO bilbo.inter.net.il) (192.114.186.18) by sources.redhat.com with SMTP; 16 Jan 2003 16:19:23 -0000 Received: from zaretsky ([80.230.234.107]) by bilbo.inter.net.il (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADC96489; Thu, 16 Jan 2003 18:18:41 +0200 (IST) Date: Thu, 16 Jan 2003 16:19:00 -0000 From: "Eli Zaretskii" To: ford@vss.fsi.com Message-Id: <4331-Thu16Jan2003181718+0200-eliz@is.elta.co.il> CC: gdb@sources.redhat.com In-reply-to: (message from Brian Ford on Wed, 15 Jan 2003 18:24:27 -0600 (CST)) Subject: Re: Non-zero VMA's w/DWARF-2? Reply-to: Eli Zaretskii References: X-SW-Source: 2003-01/txt/msg00293.txt.bz2 > Date: Wed, 15 Jan 2003 18:24:27 -0600 (CST) > From: Brian Ford > > DJGPP does not have the constraints of a PE/COFF object file format. As I > understand it, they have a wrapper that loads COFF, so they can do as they > please. That's true: a DJGPP program has a short 2KB stub loader prepended to it. To the OS, that stub is the program; the COFF image is just data which the OS knows nothing about. When the stub is invoked, it reads the COFF information from the rest of the .exe file, sets up memory as required by the sections in the image, then jumps to the start point of the COFF image.