DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 60CMoHh6090096
Authentication-Results: delorie.com; dmarc=none (p=none dis=none) header.from=delorie.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=delorie.com
X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 60CMoH1d090076
Authentication-Results: delorie.com; dmarc=pass (p=reject dis=none) header.from=zensoft.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=zensoft.com
DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 60CMoH1d090076
Authentication-Results: delorie.com;
	dkim=pass (2048-bit key, unprotected) header.d=zensoft.com header.i=@zensoft.com header.a=rsa-sha256 header.s=20121130 header.b=acaav5zg
X-Recipient: djgpp AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zensoft.com; h=content-type:message-id:date:mime-version:subject:to:references:from:in-reply-to; s=20121130; bh=pdaNrAq9/bqESLTq+2R+JixqtrPf+Gw4qTIe3XM8o+4=; b=acaav5zgYCjSxfDIoL9oTQYptkiP5VJL0ldskSbAqNDZVyneqbAZqMbD3VrxrbVlR7P5AV5u3o2MMoeOSmvqHpWhrGuZEogw63tJLcEL+7QF0P08PZ+CQcXvG3d1Ams0EKmzr1R8OzLbKK0kPMFrRVxWY2YvPAGL5bMU32nBOGZfGz12UIXh4k0WUPbCTGMMVjm2/W1xe28uHCrwj+VjK6688mONZod+auvdTWEmF5rKGo15p9hu6Bxc2Np5VHTbKbq3rV4W24d+35umQrdLe7x+flTOrywNagmmm+jvJzgiZWEDW63Ldl+GzTjnWU2gyOhIXoMFJQ0wLMM1m+PEig==
Content-Type: multipart/alternative;
 boundary="------------l0qssaH50nFaCdJA6uCOHq3F"
Message-ID: <24891d18-c57f-4639-b7c9-c4c259353a46@zensoft.com>
Date: Mon, 12 Jan 2026 16:50:09 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Supported debug info formats
To: djgpp AT delorie DOT com
References: <0752ebcc-24dd-4ea1-ad68-7822463d0eda AT polymtl DOT ca>
Content-Language: en-US
From: "Robert Sundling (rjs-djgpp AT zensoft DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
In-Reply-To: <0752ebcc-24dd-4ea1-ad68-7822463d0eda@polymtl.ca>
X-Virus-Checked: Checked by ClamAV on mx1.zsft.net
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

This is a multi-part message in MIME format.
--------------l0qssaH50nFaCdJA6uCOHq3F
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Simon,

Just to add another data point: I use DJGPP extensively for quite a few 
closed-source DOS projects. My workflow involves using modern GCC (and 
Clang) cross-compilers, targeting i686-pc-msdosdjgpp, with 
cross-compiled DJGPP tools used to create the final executable files.

I just double checked all of my projects. I am using DWARF Version 5 in 
all of them (generally using objcopy to split symbols into separate .dbg 
files). Modern DWARF works flawlessly for me, so removing COFF debug 
info support from GDB would not affect my workflow.

I also make extensive use of NASM [1] in these projects, but when 
generating COFF object files (needed to link with the other files), NASM 
cannot output debugging information of any kind, so that also does not 
matter.

Robert

[1] https://www.nasm.us/


On 1/9/2026 11:25 AM, Simon Marchi (simon DOT marchi AT polymtl DOT ca) [via 
djgpp AT delorie DOT com] wrote:
> Hi,
>
> GDB maintainer here.  I'm in the process of cleaning up obsolete things,
> like debug info formats that are not longer relevant.  I am now looking
> at COFF [1].  I am wondering if this is still useful for DJGPP, or if
> nowadays you can use DWARF like most other targets (or if people use GDB
> for DJGPP at all).
>
> In the gcc source code [1] I see this, so I guess that DWARF 2 is the
> default debug format now?
>
>      /* Support generation of DWARF2 debugging info.  */
>      #define DWARF2_DEBUGGING_INFO 1
>
>      #undef PREFERRED_DEBUGGING_TYPE
>      #define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG
>
> ...
>
>          /* Don't emit DWARF3/4 unless specifically selected. */         \
>          /* DWARF3/4 currently does not work for DJGPP.  */              \
>          if (!OPTION_SET_P (dwarf_version))                        \
>              dwarf_version = 2;                                          \
>                                                                          \
>          }                                                               \
>
> Note that I am only talking about the debug info aspects of COFF,
> there are probably some things in coffread.c that would still be needed
> in order to read executable files on Windows and/or DJGPP.
>
> Thanks,
>
> Simon
>
> [1]https://gitlab.com/gnutools/gcc/-/blob/c10076b34d3ede485bfb306b2a91feeee8368cd5/gcc/config/i386/djgpp.h#L20-24

--------------l0qssaH50nFaCdJA6uCOHq3F
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Simon,<br>
    <br>
    Just to add another data point: I use DJGPP extensively for quite a
    few closed-source DOS projects. My workflow involves using modern
    GCC (and Clang) cross-compilers, targeting i686-pc-msdosdjgpp, with
    cross-compiled DJGPP tools used to create the final executable
    files.<br>
    <br>
    I just double checked all of my projects. I am using DWARF Version 5
    in all of them (generally using objcopy to split symbols into
    separate .dbg files). Modern DWARF works flawlessly for me, so
    removing COFF debug info support from GDB would not affect my
    workflow.<br>
    <br>
    I also make extensive use of NASM [1] in these projects, but when
    generating COFF object files (needed to link with the other files),
    NASM cannot output debugging information of any kind, so that also
    does not matter.<br>
    <br>
    Robert<br>
    <br>
    [1] <a class="moz-txt-link-freetext" href="https://www.nasm.us/">https://www.nasm.us/</a><br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 1/9/2026 11:25 AM, Simon Marchi
      (<a class="moz-txt-link-abbreviated" href="mailto:simon DOT marchi AT polymtl DOT ca">simon DOT marchi AT polymtl DOT ca</a>) [via <a class="moz-txt-link-abbreviated" href="mailto:djgpp AT delorie DOT com">djgpp AT delorie DOT com</a>] wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:0752ebcc-24dd-4ea1-ad68-7822463d0eda AT polymtl DOT ca">
      <pre wrap="" class="moz-quote-pre">Hi,

GDB maintainer here.  I'm in the process of cleaning up obsolete things,
like debug info formats that are not longer relevant.  I am now looking
at COFF [1].  I am wondering if this is still useful for DJGPP, or if
nowadays you can use DWARF like most other targets (or if people use GDB
for DJGPP at all).

In the gcc source code [1] I see this, so I guess that DWARF 2 is the
default debug format now?

    /* Support generation of DWARF2 debugging info.  */
    #define DWARF2_DEBUGGING_INFO 1

    #undef PREFERRED_DEBUGGING_TYPE
    #define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG

...

        /* Don't emit DWARF3/4 unless specifically selected. */         \
        /* DWARF3/4 currently does not work for DJGPP.  */              \
        if (!OPTION_SET_P (dwarf_version))                        \
            dwarf_version = 2;                                          \
                                                                        \
        }                                                               \

Note that I am only talking about the debug info aspects of COFF,
there are probably some things in coffread.c that would still be needed
in order to read executable files on Windows and/or DJGPP.

Thanks,

Simon

[1] <a class="moz-txt-link-freetext" href="https://gitlab.com/gnutools/gcc/-/blob/c10076b34d3ede485bfb306b2a91feeee8368cd5/gcc/config/i386/djgpp.h#L20-24">https://gitlab.com/gnutools/gcc/-/blob/c10076b34d3ede485bfb306b2a91feeee8368cd5/gcc/config/i386/djgpp.h#L20-24</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------l0qssaH50nFaCdJA6uCOHq3F--