www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd

reply "Alexander Bothe" <info alexanderbothe.com> writes:
Hi everyone,

I think announcing a new Mono-D release on all operating systems
over here might be handy, as I redently wasn't able to figure out
how to build a version that is compatible to the stable MD's API,
which led me to a phase of striking against releasing a new one
on windows..but anyway, now I found a way to get it fixed, and
here it is:

http://mono-d.alexanderbothe.com/repo/MonoDevelop.D_0.5.4.1.mpack

Further info & update instructions:
http://mono-d.alexanderbothe.com/?p=1048

Issues/Bugs/Feature requests:
https://github.com/aBothe/D_Parser/issues -- Completion/Editing
https://github.com/aBothe/Mono-D/issues -- Building/Project
management/GUI/other

There's a working GDB addin for Mono-D under Linux/Mac(?) now:
https://github.com/llucenic/MonoDevelop.Debugger.Gdb.D

Are there any plans/tricks/hacks on how to get programs built
with dmd debuggable with gdb? Then we also could release the
addin for Windows as well!
(Afaik I asked the same question some time ago, but well, perhaps
something did change over the time :-))



Cheers,
Alex
Oct 08 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
 This time, the addin should be compatible to older beta 
 versions of
 MonoDevelop (like 4.0.12) as well – so feel free to simply try 
 it out.


_very_ glad to hear that. Thanks for your work!
Oct 08 2013
next sibling parent "Alexander Bothe" <info alexanderbothe.com> writes:
On Tuesday, 8 October 2013 at 13:21:17 UTC, Dicebot wrote:

 This time, the addin should be compatible to older beta 
 versions of
 MonoDevelop (like 4.0.12) as well – so feel free to simply try 
 it out.


 _very_ glad to hear that. Thanks for your work!


Can't guarantee anything! I've just work-arounded that 
IReferenceContext-missing exception, but as this was like the 
only change in the near past I hope it'll be runnable again.
Oct 08 2013
prev sibling parent reply "Alex" <info alexanderbothe.com> writes:
On Tuesday, 8 October 2013 at 13:21:17 UTC, Dicebot wrote:

 This time, the addin should be compatible to older beta 
 versions of
 MonoDevelop (like 4.0.12) as well – so feel free to simply try 
 it out.


 _very_ glad to hear that. Thanks for your work!


Tried it with 4.0.12 - it failed to open even a D file, but I
already patched it, so it hopefully works with 4.0.12 "stable"
(Arch/Ubuntu), 4.0.13 (Windows/Mac) and 4.0.17 (git master) now.
Let's pray that they won't experiment with their API another
time..
Oct 08 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Tue, 08 Oct 2013 18:43:59 +0200
schrieb "Alex" <info alexanderbothe.com>:


 On Tuesday, 8 October 2013 at 13:21:17 UTC, Dicebot wrote:

 This time, the addin should be compatible to older beta=20
 versions of
 MonoDevelop (like 4.0.12) as well =E2=80=93 so feel free to simply try=






=20

 it out.


 _very_ glad to hear that. Thanks for your work!


=20
 Tried it with 4.0.12 - it failed to open even a D file, but I
 already patched it, so it hopefully works with 4.0.12 "stable"
 (Arch/Ubuntu), 4.0.13 (Windows/Mac) and 4.0.17 (git master) now.
 Let's pray that they won't experiment with their API another
 time..


BTW:
MonoDevelop is broken on Gnome 3.10 now. They changed something
in gnome-terminal and now MonoDevelop can't open the terminal
anymore :-( Disabling the external console should work but MonoDevelop
seems to ignore that option.

Workaround: https://github.com/mono/monodevelop/pull/414
Oct 08 2013
parent "Alexander Bothe" <info alexanderbothe.com> writes:
On Tuesday, 8 October 2013 at 18:03:25 UTC, Johannes Pfau wrote:

 BTW:
 MonoDevelop is broken on Gnome 3.10 now. They changed something
 in gnome-terminal and now MonoDevelop can't open the terminal
 anymore :-( Disabling the external console should work but 
 MonoDevelop
 seems to ignore that option.

 Workaround: https://github.com/mono/monodevelop/pull/414


Okay, nice, I'll put a new build on
http://simendsjo.me/files/abothe/
as soon as it's been taken into master.
Oct 08 2013
prev sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 08/10/2013 14:18, Alexander Bothe wrote:

 Are there any plans/tricks/hacks on how to get programs built
 with dmd debuggable with gdb? Then we also could release the
 addin for Windows as well!
 (Afaik I asked the same question some time ago, but well, perhaps
 something did change over the time :-))


I was wondering the same as well... But from the lack of answers I think 
not much can be done? :/

-- 
Bruno Medeiros - Software Engineer
Oct 16 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 16 October 2013 at 12:38:40 UTC, Bruno Medeiros 
wrote:

 On 08/10/2013 14:18, Alexander Bothe wrote:

 Are there any plans/tricks/hacks on how to get programs built
 with dmd debuggable with gdb? Then we also could release the
 addin for Windows as well!
 (Afaik I asked the same question some time ago, but well, 
 perhaps
 something did change over the time :-))


 I was wondering the same as well... But from the lack of 
 answers I think not much can be done? :/


Well I do debug `dmd -gc` programs with gdb relatively 
frequently. What exactly is of interest?
Oct 16 2013
parent Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 16/10/2013 13:42, Dicebot wrote:

 On Wednesday, 16 October 2013 at 12:38:40 UTC, Bruno Medeiros wrote:

 On 08/10/2013 14:18, Alexander Bothe wrote:

 Are there any plans/tricks/hacks on how to get programs built
 with dmd debuggable with gdb? Then we also could release the
 addin for Windows as well!
 (Afaik I asked the same question some time ago, but well, perhaps
 something did change over the time :-))


 I was wondering the same as well... But from the lack of answers I
 think not much can be done? :/


 Well I do debug `dmd -gc` programs with gdb relatively frequently. What
 exactly is of interest?


We are talking about DMD+GDB on Windows.


-- 
Bruno Medeiros - Software Engineer
Oct 18 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/16/13 5:38 AM, Bruno Medeiros wrote:

 On 08/10/2013 14:18, Alexander Bothe wrote:

 Are there any plans/tricks/hacks on how to get programs built
 with dmd debuggable with gdb? Then we also could release the
 addin for Windows as well!
 (Afaik I asked the same question some time ago, but well, perhaps
 something did change over the time :-))


 I was wondering the same as well... But from the lack of answers I think
 not much can be done? :/


What are the matters involved? I did get basic debugging sessions 
working, but I forgot whether it was dmd or gdc.

Andrei
Oct 16 2013
next sibling parent reply Timothee Cour <thelastmammoth gmail.com> writes:
On Wed, Oct 16, 2013 at 2:21 PM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 10/16/13 5:38 AM, Bruno Medeiros wrote:


 On 08/10/2013 14:18, Alexander Bothe wrote:


 Are there any plans/tricks/hacks on how to get programs built
 with dmd debuggable with gdb? Then we also could release the
 addin for Windows as well!
 (Afaik I asked the same question some time ago, but well, perhaps
 something did change over the time :-))


 I was wondering the same as well... But from the lack of answers I think
 not much can be done? :/


 What are the matters involved? I did get basic debugging sessions working,
 but I forgot whether it was dmd or gdc.

 Andrei


on OSX, lldb has better support than gdb.
Oct 17 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-10-17 09:42, Timothee Cour wrote:


 on OSX, lldb has better support than gdb.


Not for D. Break points doesn't work in LLDB but they do work in GDB. 
The backtrace seem to be slightly incorrect as well. The line number for 
frame 0 is off by one. Printing a variable doesn't seem to work.

-- 
/Jacob Carlborg
Oct 17 2013
prev sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 16/10/2013 22:21, Andrei Alexandrescu wrote:

 On 10/16/13 5:38 AM, Bruno Medeiros wrote:

 On 08/10/2013 14:18, Alexander Bothe wrote:

 Are there any plans/tricks/hacks on how to get programs built
 with dmd debuggable with gdb? Then we also could release the
 addin for Windows as well!
 (Afaik I asked the same question some time ago, but well, perhaps
 something did change over the time :-))


 I was wondering the same as well... But from the lack of answers I think
 not much can be done? :/


 What are the matters involved? I did get basic debugging sessions
 working, but I forgot whether it was dmd or gdc.

 Andrei


If that was under Windows, it must have been GDC then. The debug format 
that DMD emits on Windows (OMF for x32 and COFF for x64, if I'm correct) 
is not understood by GDB, which I guess only understands DWARF.

-- 
Bruno Medeiros - Software Engineer
Oct 18 2013
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 October 2013 12:43, Bruno Medeiros <brunodomedeiros+dng gmail.com> wrote:

 On 16/10/2013 22:21, Andrei Alexandrescu wrote:

 On 10/16/13 5:38 AM, Bruno Medeiros wrote:

 On 08/10/2013 14:18, Alexander Bothe wrote:

 Are there any plans/tricks/hacks on how to get programs built
 with dmd debuggable with gdb? Then we also could release the
 addin for Windows as well!
 (Afaik I asked the same question some time ago, but well, perhaps
 something did change over the time :-))



 I was wondering the same as well... But from the lack of answers I think
 not much can be done? :/



 What are the matters involved? I did get basic debugging sessions
 working, but I forgot whether it was dmd or gdc.

 Andrei


 If that was under Windows, it must have been GDC then. The debug format that
 DMD emits on Windows (OMF for x32 and COFF for x64, if I'm correct) is not
 understood by GDB, which I guess only understands DWARF.


GCC is able to emit COFF object code - and GDB can read COFF debug
code - though admitedly COFF is a woeful excuse of an object/debug
file format.  :o)

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 18 2013
parent Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 18/10/2013 12:58, Iain Buclaw wrote:

 On 18 October 2013 12:43, Bruno Medeiros <brunodomedeiros+dng gmail.com> wrote:

 On 16/10/2013 22:21, Andrei Alexandrescu wrote:

 On 10/16/13 5:38 AM, Bruno Medeiros wrote:

 On 08/10/2013 14:18, Alexander Bothe wrote:

 Are there any plans/tricks/hacks on how to get programs built
 with dmd debuggable with gdb? Then we also could release the
 addin for Windows as well!
 (Afaik I asked the same question some time ago, but well, perhaps
 something did change over the time :-))



 I was wondering the same as well... But from the lack of answers I think
 not much can be done? :/



 What are the matters involved? I did get basic debugging sessions
 working, but I forgot whether it was dmd or gdc.

 Andrei


 If that was under Windows, it must have been GDC then. The debug format that
 DMD emits on Windows (OMF for x32 and COFF for x64, if I'm correct) is not
 understood by GDB, which I guess only understands DWARF.


 GCC is able to emit COFF object code - and GDB can read COFF debug
 code - though admitedly COFF is a woeful excuse of an object/debug
 file format.  :o)

 Regards


Thanks for the clarification, I didn't know GDB could read COFF as well.

My main dev machine is 32 bit (old yeah) so I haven't had yet the chance 
to try DMD-64 on Windows. Will probably try it at some point on my desktop.

-- 
Bruno Medeiros - Software Engineer
Oct 22 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On 18 October 2013 21:58, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 On 18 October 2013 12:43, Bruno Medeiros <brunodomedeiros+dng gmail.com>
 wrote:

 On 16/10/2013 22:21, Andrei Alexandrescu wrote:

 On 10/16/13 5:38 AM, Bruno Medeiros wrote:

 On 08/10/2013 14:18, Alexander Bothe wrote:

 Are there any plans/tricks/hacks on how to get programs built
 with dmd debuggable with gdb? Then we also could release the
 addin for Windows as well!
 (Afaik I asked the same question some time ago, but well, perhaps
 something did change over the time :-))



 I was wondering the same as well... But from the lack of answers I






 think

 not much can be done? :/



 What are the matters involved? I did get basic debugging sessions
 working, but I forgot whether it was dmd or gdc.

 Andrei


 If that was under Windows, it must have been GDC then. The debug format


 that

 DMD emits on Windows (OMF for x32 and COFF for x64, if I'm correct) is


 not

 understood by GDB, which I guess only understands DWARF.


 GCC is able to emit COFF object code - and GDB can read COFF debug
 code - though admitedly COFF is a woeful excuse of an object/debug
 file format.  :o)


DMD for Win64 uses COFF so it's compatible with the windows ecosystem at
large (and ideally Win32 will move that way too in the future). Almost all
dev tools/environments/libraries are distributed as MS-COFF libs.

GCC COFF output isn't very useful in the windows context. I tried it. It
tried to link, but GCC produces countless intrinsic calls to the gnu
runtime libs, and they are quite incompatible with the MS CRT. It also
seems to populate the COFF objects with DWARF debug info instead of CV8
that VisualC's linker extracts and writes into a PDB file, so you can't
debug GDC's COFF output with standard tools.

So if you're not interacting with the MS ecosystem (the de facto standard
on windows), then you might as well just use elf + dwarf from GCC.

I guess the usefulness of Mono-D in windows is an environment that DOES
support building+linking+debugging elf+dwarf based projects. This does
exclude DMD, since it primarily tries to work in conjunction with the OS
standards, but there's plenty of reasons to want to work with GDC in
windows, and Mono-D would be the go-to environment for that.

Ideally I'd like a command-line choice of object+debug format from all
compilers so they can work in either of windows's fragmented ecosystems...
but due to the intrinsic calls to glibc thing, GDC doesn't seem like it
will ever be a good match for developing windows code. LDC seems promising
that it may support either ecosystem, and DMD could theoretically write
ELF+DWARF on a command line switch (it obviously has code to write those
formats), but I haven't seen much demand for it.
Oct 22 2013
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 22 October 2013 13:29, Manu <turkeyman gmail.com> wrote:

 On 18 October 2013 21:58, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 18 October 2013 12:43, Bruno Medeiros <brunodomedeiros+dng gmail.com>
 wrote:

 On 16/10/2013 22:21, Andrei Alexandrescu wrote:

 On 10/16/13 5:38 AM, Bruno Medeiros wrote:

 On 08/10/2013 14:18, Alexander Bothe wrote:

 Are there any plans/tricks/hacks on how to get programs built
 with dmd debuggable with gdb? Then we also could release the
 addin for Windows as well!
 (Afaik I asked the same question some time ago, but well, perhaps
 something did change over the time :-))



 I was wondering the same as well... But from the lack of answers I
 think
 not much can be done? :/



 What are the matters involved? I did get basic debugging sessions
 working, but I forgot whether it was dmd or gdc.

 Andrei


 If that was under Windows, it must have been GDC then. The debug format
 that
 DMD emits on Windows (OMF for x32 and COFF for x64, if I'm correct) is
 not
 understood by GDB, which I guess only understands DWARF.


 GCC is able to emit COFF object code - and GDB can read COFF debug
 code - though admitedly COFF is a woeful excuse of an object/debug
 file format.  :o)



 DMD for Win64 uses COFF so it's compatible with the windows ecosystem at
 large (and ideally Win32 will move that way too in the future). Almost all
 dev tools/environments/libraries are distributed as MS-COFF libs.

 GCC COFF output isn't very useful in the windows context. I tried it. It
 tried to link, but GCC produces countless intrinsic calls to the gnu runtime
 libs, and they are quite incompatible with the MS CRT. It also seems to
 populate the COFF objects with DWARF debug info instead of CV8 that
 VisualC's linker extracts and writes into a PDB file, so you can't debug
 GDC's COFF output with standard tools.


Incompatibility with MS CRT has nothing to do with COFF. :o)

Also, it's not likely DWARF debug information that it emits, as the
COFF object format defines its own intrinsic symbolic debug format.
GDB can't read CV8/PDB.

If you are using GCC, you'll be using the GCC toolchain.  If you are
using MSVC, you'll be using the MSVC toolchain.  It's as black and
white as that.



 So if you're not interacting with the MS ecosystem (the de facto standard on
 windows), then you might as well just use elf + dwarf from GCC.


Except that GCC does not emit ELF on windows.  ;-)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 22 2013
parent Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 22/10/2013 14:48, Iain Buclaw wrote:

 If you are using GCC, you'll be using the GCC toolchain.  If you are
 using MSVC, you'll be using the MSVC toolchain.  It's as black and
 white as that.


I know. The point, for me at least, was not weather I could use GCC + MS 
debuggers or MS compilers + GDB. It was: if you use DMD (64 bit ATM) 
what debuggers can you use? Can you sucessfully use GDB? If not, could 
DMD be modified to supported whatever format GDB uses?


 Also, it's not likely DWARF debug information that it emits, as the
 COFF object format defines its own intrinsic symbolic debug format.
 GDB can't read CV8/PDB.


I think it's DWARF debug information, even for COFF and PE file format. 
If I run "info source" on a GDC compiled program, I get:
------
(gdb) info source
Current source file is ../../../gcc-4.6.1/libphobos/rt/dmain.d
Compilation directory is C:\crossdev\gdc\v2\build\i686-pc-mingw32\libphobos
Source language is d.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.
------

I suspect that what is happening is that by default GCC toolchain stores 
debug information in the COFF (and PE) file format in a non-standard way 
- it doesn't use the COFF debug standard but uses DWARF data format 
instead (DWARF "is independent of object file formats"). And that's why 
MS tools don't understand that symbolic info, I guess.


-- 
Bruno Medeiros - Software Engineer
Oct 23 2013
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 22 October 2013 23:48, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 On 22 October 2013 13:29, Manu <turkeyman gmail.com> wrote:

 On 18 October 2013 21:58, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 18 October 2013 12:43, Bruno Medeiros <brunodomedeiros+dng gmail.com



 wrote:

 On 16/10/2013 22:21, Andrei Alexandrescu wrote:

 On 10/16/13 5:38 AM, Bruno Medeiros wrote:

 On 08/10/2013 14:18, Alexander Bothe wrote:

 Are there any plans/tricks/hacks on how to get programs built
 with dmd debuggable with gdb? Then we also could release the
 addin for Windows as well!
 (Afaik I asked the same question some time ago, but well, perhaps
 something did change over the time :-))



 I was wondering the same as well... But from the lack of answers I
 think
 not much can be done? :/



 What are the matters involved? I did get basic debugging sessions
 working, but I forgot whether it was dmd or gdc.

 Andrei


 If that was under Windows, it must have been GDC then. The debug






 format

 that
 DMD emits on Windows (OMF for x32 and COFF for x64, if I'm correct) is
 not
 understood by GDB, which I guess only understands DWARF.


 GCC is able to emit COFF object code - and GDB can read COFF debug
 code - though admitedly COFF is a woeful excuse of an object/debug
 file format.  :o)



 DMD for Win64 uses COFF so it's compatible with the windows ecosystem at
 large (and ideally Win32 will move that way too in the future). Almost


 all

 dev tools/environments/libraries are distributed as MS-COFF libs.

 GCC COFF output isn't very useful in the windows context. I tried it. It
 tried to link, but GCC produces countless intrinsic calls to the gnu


 runtime

 libs, and they are quite incompatible with the MS CRT. It also seems to
 populate the COFF objects with DWARF debug info instead of CV8 that
 VisualC's linker extracts and writes into a PDB file, so you can't debug
 GDC's COFF output with standard tools.


 Incompatibility with MS CRT has nothing to do with COFF. :o)


I didn't say that it did.
It's a practical problem. it makes GCC COFF output kinda pointless.

Also, it's not likely DWARF debug information that it emits, as the

 COFF object format defines its own intrinsic symbolic debug format.
 GDB can't read CV8/PDB.


Well I can say from experience that GDC built to output COFF was able to
link using the MS linker (although there are loads of problems due to CRT
conflicts), but it didn't see the debug information at all.
So whatever it writes is apparently not recognised by link.exe (mustn't be
VC8?)...

I'm aware GDB can't read CV8/PDB, I'm not sure what your point is?
I was just adding detail to your post about the state of COFF support in
Windows.

If you are using GCC, you'll be using the GCC toolchain.  If you are

 using MSVC, you'll be using the MSVC toolchain.  It's as black and
 white as that.


Yes, that's basically the point I was making... and it influences your
choice of D compilers, and tooling, hence Mono-D has a place in Windows
even though it may not support DMD for debugging.


 So if you're not interacting with the MS ecosystem (the de facto standard
 on

 windows), then you might as well just use elf + dwarf from GCC.


 Except that GCC does not emit ELF on windows.  ;-)


Really? What is it?
Well whatever object format it is, it seems it's not COFF by default, and
appears it does support DWARF since I've debugged GCC code with GDB before.
Oct 22 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 22 October 2013 at 14:39:55 UTC, Manu wrote:

 Well whatever object format it is, it seems it's not COFF by 
 default, [...]


---
$ gcc --version && gcc -c test.c && file test.o
gcc.exe (rubenvb-4.8.0) 4.8.0
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  
There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A 
PARTICULAR PURPOSE.

test.o: MS Windows COFF Intel 80386 object file
---

David
Oct 22 2013
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 22 October 2013 15:58, David Nadlinger <code klickverbot.at> wrote:

 On Tuesday, 22 October 2013 at 14:39:55 UTC, Manu wrote:

 Well whatever object format it is, it seems it's not COFF by default,
 [...]



 ---
 $ gcc --version && gcc -c test.c && file test.o
 gcc.exe (rubenvb-4.8.0) 4.8.0
 Copyright (C) 2013 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 test.o: MS Windows COFF Intel 80386 object file
 ---


Thanks for having faith in my words... :o)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 22 2013
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 23 October 2013 01:02, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 On 22 October 2013 15:58, David Nadlinger <code klickverbot.at> wrote:

 On Tuesday, 22 October 2013 at 14:39:55 UTC, Manu wrote:

 Well whatever object format it is, it seems it's not COFF by default,
 [...]



 ---
 $ gcc --version && gcc -c test.c && file test.o
 gcc.exe (rubenvb-4.8.0) 4.8.0
 Copyright (C) 2013 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is


 NO

 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR


 PURPOSE.

 test.o: MS Windows COFF Intel 80386 object file
 ---


 Thanks for having faith in my words... :o)


...okay. Ignore me!
You said "GCC _is able_ to emit COFF object code", which didn't make it
sound like it did, or at least not by default. Which seemed to match my
experience (from years ago).
I recall a conversation with Daniel Green about making a special
COFF-outputting toolchain for me.
So what debuginfo is in there then? MS link.exe seemed to ignore it.

So, you are saying that GDC does output COFF by default? And is debuggable
by gdb?
I'm thoroughly confused now, this seems to contradict past experiences.
Apparently I've been smoking a lot of crack...
What are the object+debuginfo formats supported by LDC?
Oct 22 2013
parent Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 22/10/2013 16:59, Manu wrote:

 ...okay. Ignore me!
 You said "GCC _is able_ to emit COFF object code", which didn't make it
 sound like it did, or at least not by default. Which seemed to match my
 experience (from years ago).
 I recall a conversation with Daniel Green about making a special
 COFF-outputting toolchain for me.
 So what debuginfo is in there then? MS link.exe seemed to ignore it.

 So, you are saying that GDC does output COFF by default? And is
 debuggable by gdb?
 I'm thoroughly confused now, this seems to contradict past experiences.
 Apparently I've been smoking a lot of crack...


See my OP. It seems by default GDC outputs COFF object file format, but 
with DWARF debug info.

But whatever format it is, GDB understands it quite well, that is for 
sure. GDC+GDB was the main configuration I tested when I was updating 
the Debuggers wiki page and see what kind of support there was.


-- 
Bruno Medeiros - Software Engineer
Oct 23 2013
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 22 October 2013 16:59, Manu <turkeyman gmail.com> wrote:

 On 23 October 2013 01:02, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 22 October 2013 15:58, David Nadlinger <code klickverbot.at> wrote:

 On Tuesday, 22 October 2013 at 14:39:55 UTC, Manu wrote:

 Well whatever object format it is, it seems it's not COFF by default,
 [...]



 ---
 $ gcc --version && gcc -c test.c && file test.o
 gcc.exe (rubenvb-4.8.0) 4.8.0
 Copyright (C) 2013 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is
 NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
 PURPOSE.

 test.o: MS Windows COFF Intel 80386 object file
 ---


 Thanks for having faith in my words... :o)



 ...okay. Ignore me!
 You said "GCC _is able_ to emit COFF object code", which didn't make it
 sound like it did, or at least not by default. Which seemed to match my
 experience (from years ago).
 I recall a conversation with Daniel Green about making a special
 COFF-outputting toolchain for me.
 So what debuginfo is in there then? MS link.exe seemed to ignore it.

 So, you are saying that GDC does output COFF by default? And is debuggable
 by gdb?
 I'm thoroughly confused now, this seems to contradict past experiences.
 Apparently I've been smoking a lot of crack...


Or eating the wrong mushrooms.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 22 2013