|
Archives
D Programming
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.ide
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
D.gnu
D
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
electronics
|
digitalmars.D.announce - ldc 0.9.1 released
The release 0.9.1 of LDC, the LLVM based compiler for the D programming
language, contains the following major improvements:
* lots of bug fixes (http://www.dsource.org/projects/ldc/report/15)
* x86-64 support is mature
* inline asm improved (we now define D_Inline_Asm)
* cross-compilation support
* uses boehm-gc during compilation (x86-32 only)
* D specific optimizations:
* turn GC allocations to allocas if possible
* simplify or remove certain calls to D runtime functions
The command line interface of LDC now has added options in line with other
LLVM based tools. Please use the ldmd wrapper if you want a drop-in
replacement for DMD.
Linux x86-32 download:
http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_32.tar.bz2
Linux x86-64 download:
http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_64.tar.bz2
Tomas Lindquist Olsen
Christian Kamm
Frits van Bommel
Kelly Wilson
Christian Kamm wrote:
The release 0.9.1 of LDC, the LLVM based compiler for the D programming
language, contains the following major improvements:
* lots of bug fixes (http://www.dsource.org/projects/ldc/report/15)
* x86-64 support is mature
* inline asm improved (we now define D_Inline_Asm)
* cross-compilation support
* uses boehm-gc during compilation (x86-32 only)
* D specific optimizations:
* turn GC allocations to allocas if possible
* simplify or remove certain calls to D runtime functions
The command line interface of LDC now has added options in line with other
LLVM based tools. Please use the ldmd wrapper if you want a drop-in
replacement for DMD.
Linux x86-32 download:
http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_32.tar.bz2
Linux x86-64 download:
http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_64.tar.bz2
Tomas Lindquist Olsen
Christian Kamm
Frits van Bommel
Kelly Wilson
Great! Quick question - are you supporting or considering supporting D2?
I looked on the project's home page and couldn't find that information.
There's mention of druntime for D2 which makes me hopeful.
Thanks,
Andrei
Andrei Alexandrescu wrote:
Great! Quick question - are you supporting or considering supporting D2?
I looked on the project's home page and couldn't find that information.
There's mention of druntime for D2 which makes me hopeful.
Thanks,
Andrei
D2 support in LDC has been started, but it does not have any of D2's
features implemented. I believe all that has been done is the frontend
added. Last time I checked ldc + d2 would not compile.
I believe that the plan is to make D1 solid (more so than DMD), before
moving on to D2. One of the developers might be able to give a more
accurate status.
Robert Clipsham wrote:
Andrei Alexandrescu wrote:
Great! Quick question - are you supporting or considering supporting
D2? I looked on the project's home page and couldn't find that
information. There's mention of druntime for D2 which makes me hopeful.
Thanks,
Andrei
D2 support in LDC has been started, but it does not have any of D2's
features implemented. I believe all that has been done is the frontend
added. Last time I checked ldc + d2 would not compile.
I believe that the plan is to make D1 solid (more so than DMD), before
moving on to D2. One of the developers might be able to give a more
accurate status.
That's pretty accurate, actually.
A while back somebody sent in a patch to get D2 support working, but by the
time
it got properly reviewed it was already outdated...
The main problem on this front is that nobody currently working on LDC is
particularly interested in D2.
Frits van Bommel wrote:
Robert Clipsham wrote:
Andrei Alexandrescu wrote:
Great! Quick question - are you supporting or considering supporting
D2? I looked on the project's home page and couldn't find that
information. There's mention of druntime for D2 which makes me hopeful.
Thanks,
Andrei
D2 support in LDC has been started, but it does not have any of D2's
features implemented. I believe all that has been done is the frontend
added. Last time I checked ldc + d2 would not compile.
I believe that the plan is to make D1 solid (more so than DMD), before
moving on to D2. One of the developers might be able to give a more
accurate status.
That's pretty accurate, actually.
A while back somebody sent in a patch to get D2 support working, but by
the time it got properly reviewed it was already outdated...
The main problem on this front is that nobody currently working on LDC
is particularly interested in D2.
I actually thought about giving this a try about a week ago. I managed
to get all but one file to compile with the current version of the D2
front end (2.021 I believe)... Not bad considering my (lack of) C/C++
knowledge. If there's some interest for it I suppose I could give it
another shot and try to merge the latest front end, it'd be a good
chance for me to finally learn C/C++ (I made the <del>mistake</del>
decision to learn D first... I found it too awesome to bother learning
the obviously inferior C/C++ :P).
Robert Clipsham wrote:
...
I actually thought about giving this a try about a week ago. I managed
to get all but one file to compile with the current version of the D2
front end (2.021 I believe)... Not bad considering my (lack of) C/C++
knowledge. If there's some interest for it I suppose I could give it
another shot and try to merge the latest front end, it'd be a good
chance for me to finally learn C/C++ (I made the <del>mistake</del>
decision to learn D first... I found it too awesome to bother learning
the obviously inferior C/C++ :P).
I'm interested, for sure.
Robert Clipsham Wrote:
Not bad considering my (lack of) C/C++
knowledge. If there's some interest for it I suppose I could give it
another shot and try to merge the latest front end, it'd be a good
chance for me to finally learn C/C++ (I made the <del>mistake</del>
decision to learn D first... I found it too awesome to bother learning
the obviously inferior C/C++ :P).
I found recently that properly designed C++ code can live happily without all
that esoteric macro/template crap and can be pretty readable and understandable
even using nasty antipatterns. This being achieved simply by using C++ subset
that is supported on various platforms. Code that does the job instead of
casting black magic.
Kagamin wrote:
I found recently that properly designed C++ code can live happily
without all that esoteric macro/template crap and can be pretty
readable and understandable even using nasty antipatterns. This being
achieved simply by using C++ subset that is supported on various
platforms. Code that does the job instead of casting black magic.
The D compiler source doesn't use any templates, rtti, or clever macro
hacks. Whether it's well designed or not, I'll let others decide. It is
written in a "D-ish" style.
Walter Bright wrote:
The D compiler source doesn't use any templates, rtti, or clever macro
hacks. Whether it's well designed or not, I'll let others decide. It is
written in a "D-ish" style.
I ported part of the DMDFE to Java, and found it quite well-designed
(with the exception of the frequent use of globals). The gotos make it
more readable IMO (compare the original to the Java version where gotos
are replaced with exceptions, replaced with duplicated code, emulated
with a bunch of booleans, or refactored into separate functions taking
7+ arguments).
However, the DMDFE's organization relies on being able to declare class
member functions separately from where they're defined, which is
impossible in D (hint, hint, nudge, nudge).
Robert Fraser:
However, the DMDFE's organization relies on being able to declare class
member functions separately from where they're defined, which is
impossible in D (hint, hint, nudge, nudge).
This current characteristics of D classes makes them a bit simpler to
read/understand/use.
Can you tell me (and/or show a small example) where you think such separation
may improve some D code?
Bye,
bearophile
"bearophile" <bearophileHUGS lycos.com> wrote in message
news:gvmtt5$5os$1 digitalmars.com...
Robert Fraser:
However, the DMDFE's organization relies on being able to declare class
member functions separately from where they're defined, which is
impossible in D (hint, hint, nudge, nudge).
This current characteristics of D classes makes them a bit simpler to
read/understand/use.
Can you tell me (and/or show a small example) where you think such
separation may improve some D code?
Yea, I haven't seen anything yet about lifting the one-to-one module-to-file
mapping that would make breaking bud/rebuild-like tools worthwhile. But I'd
be interested in hearing any arguments in favor of doing so.
"Walter Bright" <newshound1 digitalmars.com> wrote in message
news:gvml4m$2lg0$2 digitalmars.com...
Kagamin wrote:
I found recently that properly designed C++ code can live happily
without all that esoteric macro/template crap and can be pretty
readable and understandable even using nasty antipatterns. This being
achieved simply by using C++ subset that is supported on various
platforms. Code that does the job instead of casting black magic.
The D compiler source doesn't use any templates, rtti, or clever macro
hacks. Whether it's well designed or not, I'll let others decide. It is
written in a "D-ish" style.
As someone who's (deliberately) barely touched C++ in about ten years, I
found it surprisingly easy to find my way around. Although I did find it
strange that there seemed to be a fair amount of duplicated code (at least
WRT to error/warning reporting anyway).
Kagamin wrote:
I found recently that properly designed C++ code can live happily without all
that esoteric macro/template crap and can be pretty readable and understandable
even using nasty antipatterns. This being achieved simply by using C++ subset
that is supported on various platforms. Code that does the job instead of
casting black magic.
The problem is trying to get an entire team to code that way.
On Wed, May 27, 2009 at 9:32 PM, Frits van Bommel
<fvbommel remwovexcapss.nl> wrote:
Robert Clipsham wrote:
Andrei Alexandrescu wrote:
Great! Quick question - are you supporting or considering supporting D2?
I looked on the project's home page and couldn't find that information.
There's mention of druntime for D2 which makes me hopeful.
Thanks,
Andrei
D2 support in LDC has been started, but it does not have any of D2's
features implemented. I believe all that has been done is the frontend
added. Last time I checked ldc + d2 would not compile.
I believe that the plan is to make D1 solid (more so than DMD), before
moving on to D2. One of the developers might be able to give a more accurate
status.
That's pretty accurate, actually.
A while back somebody sent in a patch to get D2 support working, but by the
time it got properly reviewed it was already outdated...
The main problem on this front is that nobody currently working on LDC is
particularly interested in D2.
The way the frontend is developed is also a factor.
Right now we have two frontend source dirs. One for D1 and one for D2.
Every time a new DMD release is out, this means: cleaning out the
files we don't need (or can't use) in LDC, merging the changes into
LDC, repeating for D2.
But merging isn't always trivial. Since we have quite a lot of changes
and conflicts are common.
Also often LDC bugreports are frontend related, and both D1 and D2
need identical fixes applied, this is often forgotten.
So, for now we're focusing on D1 and unfortunately D2 has fallen
behind to a point where it's just plain broken.
I would like to see more improvements to the way the DMD frontend is
developed - regarding other users than the DMD compiler - before
picking up D2 again. More specifically:
* Seperation of frontend and backend needs to be more clear. The file
structure is one thing, but it would be nice if the DMD backend
specific parts in the frontend code could be versioned out for DMD. A
simple ` #if IN_DMD ' would be a big improvement.
* put the code under version control, that could simplify pulling
fixes into our tree.
I was going to put a few more entries on this list, but I could
probably provide some patches there instead of just asking for things
to happen .. But the main point is, D1 support is more than enough
work already, however these two simple improvements would be a big
help, and will benefit others who wish to use the frontend in the
future as well.
-Tomas
Op Thu, 28 May 2009 03:08:45 +0200 schreef Tomas Lindquist Olsen
<tomas.l.olsen gmail.com>:
* put the code under version control, that could simplify pulling
fixes into our tree.
You could setup a seperate branch with the DMD source, extract source
tarball, commit.
Then merge the DMDFE branch into the LDC branches.
I dont know how to do this in hg, but i guess its very similar to git.
Or is it already done this way?
Christian Kamm wrote:
The release 0.9.1 of LDC, the LLVM based compiler for the D programming
language, contains the following major improvements:
* lots of bug fixes (http://www.dsource.org/projects/ldc/report/15)
* x86-64 support is mature
* inline asm improved (we now define D_Inline_Asm)
* cross-compilation support
* uses boehm-gc during compilation (x86-32 only)
* D specific optimizations:
* turn GC allocations to allocas if possible
* simplify or remove certain calls to D runtime functions
The command line interface of LDC now has added options in line with other
LLVM based tools. Please use the ldmd wrapper if you want a drop-in
replacement for DMD.
Linux x86-32 download:
http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_32.tar.bz2
Linux x86-64 download:
http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_64.tar.bz2
Tomas Lindquist Olsen
Christian Kamm
Frits van Bommel
Kelly Wilson
Congratulations on your hard work! This is a really big step for LDC and
D, so thanks!
On Wed, May 27, 2009 at 2:19 PM, Christian Kamm
<kamm-incasoftware removethis.de> wrote:
The release 0.9.1 of LDC, the LLVM based compiler for the D programming
language, contains the following major improvements:
=A0* lots of bug fixes (http://www.dsource.org/projects/ldc/report/15)
=A0* x86-64 support is mature
=A0* inline asm improved (we now define D_Inline_Asm)
=A0* cross-compilation support
=A0* uses boehm-gc during compilation (x86-32 only)
=A0* D specific optimizations:
=A0 * turn GC allocations to allocas if possible
=A0 * simplify or remove certain calls to D runtime functions
The command line interface of LDC now has added options in line with othe=
LLVM based tools. Please use the ldmd wrapper if you want a drop-in
replacement for DMD.
Linux x86-32 download:
http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_32.tar.bz2
Linux x86-64 download:
http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_64.tar.bz2
Rock on!
Christian Kamm, el 27 de mayo a las 20:19 me escribiste:
The release 0.9.1 of LDC, the LLVM based compiler for the D programming
language, contains the following major improvements:
* lots of bug fixes (http://www.dsource.org/projects/ldc/report/15)
* x86-64 support is mature
* inline asm improved (we now define D_Inline_Asm)
* cross-compilation support
* uses boehm-gc during compilation (x86-32 only)
* D specific optimizations:
* turn GC allocations to allocas if possible
* simplify or remove certain calls to D runtime functions
The command line interface of LDC now has added options in line with other
LLVM based tools. Please use the ldmd wrapper if you want a drop-in
replacement for DMD.
Great, great news! Thanks for the hard work.
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Christian Kamm:
The release 0.9.1 of LDC, the LLVM based compiler for the D programming
language, contains the following major improvements:
Very good. I'll try this too.
* turn GC allocations to allocas if possible
Phobos1 of DMD too has alloca, so can this optimization be folded in DMD too?
* simplify or remove certain calls to D runtime functions
What calls?
Bye,
bearophile
bearophile wrote:
* turn GC allocations to allocas if possible
I doubt it, these look like LLVM specific optimisations.
* simplify or remove certain calls to D runtime functions
Looking at the source code (gen/passes/*.cpp):
* _d_arraysetlengthT
* _d_arraysetlengthiT
* _d_array_cast_len
* _d_array_slice_copy
* _d_allocmemoryT
* _d_newarrayT
* _d_newarrayiT
* _d_newarrayvT
* _d_newarraymT
* _d_newarraymiT
* _d_newarraymvT
* _d_allocclass
Are the runtime calls currently optimized. There may be more that I've
missed, that looks like all of them though.
bearophile, el 27 de mayo a las 15:55 me escribiste:
Christian Kamm:
The release 0.9.1 of LDC, the LLVM based compiler for the D programming
language, contains the following major improvements:
Very good. I'll try this too.
* turn GC allocations to allocas if possible
Phobos1 of DMD too has alloca, so can this optimization be folded in DMD too?
I don't think so, they are D specific LLVM optimization passes, see:
http://www.dsource.org/projects/ldc/browser/gen/passes
* simplify or remove certain calls to D runtime functions
What calls?
From what I saw in:
http://www.dsource.org/projects/ldc/browser/gen/passes/SimplifyDRuntimeCalls.cpp
- Remove libcall for arr.length = N if N <= arr.length
- Remove libcall for cast(T[]) arr if it's safe to do so.
- Remove libcall if the return value is unused.
- Turn slice copies into llvm.memcpy when safe
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
bearophile wrote:
Christian Kamm:
The release 0.9.1 of LDC, the LLVM based compiler for the D programming
language, contains the following major improvements:
Very good. I'll try this too.
* turn GC allocations to allocas if possible
Phobos1 of DMD too has alloca, so can this optimization be folded in DMD too?
These optimizations are done on LLVM IR, so unless DMD switches to LLVM they'll
need to be completely reimplemented for DMD.
This one is only done for certain GC allocations by the way, not all of them.
The ones currently implemented are:
* new Struct/int/float/etc.,
* uninitialized arrays (used for arr1 ~ arr2, for instance),
* zero-initialized arrays (e.g. new int[N])
* new Class, unless
a) it has a destructor,
b) it has a custom allocator (overloads new), or
c) it has a custom deallocator (overloads delete).
* simplify or remove certain calls to D runtime functions
What calls?
Besides the GC calls turned into allocas, these are currently implemented:
* For "arr.length = N", the runtime call is deleted if
a) the resulting .ptr is unused,
b) N == 0, or
c) both arr.length and N are constant integers, and N <= arr.length.
I'd like to extend this one to a more general N <= arr.length (i.e. not
just constant integers), but I'm not quite sure what the best way to implement
it is yet.
* For "cast(T[]) some_array", the compiler generates a runtime call to
compute
the new array length. This call will be optimized out if
a) the old length was 0,
b) T.sizeof == U.sizeof, where U is the element type of some_array, or
c) T.sizeof % U.sizeof == 0
* arr1[] = arr2[] is turned into a memcpy() if alias analysis can prove they
don't overlap. (Only relevant if assertions or array bounds checks are enabled,
as they both are by default, otherwise they're turned into memcpy() in the
first
place)
* Runtime calls that don't do anything but allocate GC memory (and optionally
initialize it) are deleted if their return value is unused.
Frits van Bommel:
Thank you for your answers.
This one is only done for certain GC allocations by the way, not all of them.
The ones currently implemented are:
* new Struct/int/float/etc.,
* uninitialized arrays (used for arr1 ~ arr2, for instance),
* zero-initialized arrays (e.g. new int[N])
* new Class, unless
a) it has a destructor,
b) it has a custom allocator (overloads new), or
c) it has a custom deallocator (overloads delete).
I'm trying to find situations where that's true, but in two small programs that
use both structs and classes (that don't escape the scope and follow your
unless list) I see:
call _d_allocmemoryT
call _d_allocclass
Are those calls to variants of alloca()?
While looking for those alloca I have also tested code that has the following
two lines one after the other:
auto a = new int[1000];
a[] = 2;
That code is very common, because you currently can't write:
auto a = new int[1000] = 2;
The latest LDC compiles that as:
pushl %esi
subl $4016, %esp
leal 16(%esp), %esi
movl %esi, (%esp)
movl $4000, 8(%esp)
movl $0, 4(%esp)
call memset
movl %esi, (%esp)
movl $2, 8(%esp)
movl $1000, 4(%esp)
call _d_array_init_i32
I think the memset may be avoided.
Bye and thank you,
bearophile
bearophile wrote:
Frits van Bommel:
Thank you for your answers.
This one is only done for certain GC allocations by the way, not all of them.
The ones currently implemented are:
* new Struct/int/float/etc.,
* uninitialized arrays (used for arr1 ~ arr2, for instance),
* zero-initialized arrays (e.g. new int[N])
* new Class, unless
a) it has a destructor,
b) it has a custom allocator (overloads new), or
c) it has a custom deallocator (overloads delete).
I'm trying to find situations where that's true, but in two small programs
that use both structs and classes (that don't escape the scope and follow your
unless list) I see:
call _d_allocmemoryT
call _d_allocclass
Are those calls to variants of alloca()?
No, those are GC allocations.
This small program contains no gc allocations with ldc -O3:
-----
struct Struct {
int i, j = 4;
}
class Class {
int i, j = 6;
}
int frob(T)(T t) {
t.i = 4;
return t.j;
}
int withStruct() {
return frob(new Struct);
}
int withClass() {
return frob(new Class);
}
-----
It does still contain them when inlining is disabled, as it is by default with
-O2 (aka -O); this seems to be because the LLVM pass that adds parameter
attributes (like nocapture, better known as 'scope' in these newsgroups) is
missing from the default list of optimizations :(. I'll fix this in the
repository soon.
Another constraint I forgot to mention: it doesn't work for allocations in
loops, because it's tricky to figure out whether the allocation is still
reachable when the loop reaches the same position again.
(For this reason, the pass by default runs before each inliner run and once
after all inlining is done since the inliner can inline code into loops, yet
allows for simplifications that make escape analysis more accurate)
While looking for those alloca I have also tested code that has the following
two lines one after the other:
auto a = new int[1000];
a[] = 2;
That code is very common, because you currently can't write:
auto a = new int[1000] = 2;
The latest LDC compiles that as:
pushl %esi
subl $4016, %esp
leal 16(%esp), %esi
movl %esi, (%esp)
movl $4000, 8(%esp)
movl $0, 4(%esp)
call memset
movl %esi, (%esp)
movl $2, 8(%esp)
movl $1000, 4(%esp)
call _d_array_init_i32
I think the memset may be avoided.
That's trickier to get right, because the optimizer would have to look ahead to
see the new memset call is always followed by the initialization, with no reads
in between.
The 1-byte element case can probably be handled by LLVM if _d_array_init_i8 is
replaced by another memset, though. (and similarly, _d_array_init_i16 could be
handled for cases like 0xFFFF, but not 0x1234, by turning it into memset).
Frits van Bommel:
Thanks for your answers (and your work).
That's trickier to get right, because the optimizer would have to look ahead
to
see the new memset call is always followed by the initialization, with no
reads
in between.
I understand, and that may be more complex to do if the code is multi-thread.
It's not a very important optimization, because most times the initialization
time is a small percentage of the time spent to process the array. But it may
deserve to receive a look as a medium-low-priority optimization anyway.
Bye,
bearophile
First of all: Thanks for your your great work.
Unfortunately I still have the debugging problem already described in
the debugger group (using the x86-64 build on Ubuntu 9.04).
I compile a programm using
ldmd -g -debug test.d
Then I try to debug using gdb with the D patches:
(gdb) list
1 ../sysdeps/x86_64/elf/start.S: No such file or directory.
in ../sysdeps/x86_64/elf/start.S
Any hints on this?
Thanks and best regards,
Timo
Timo Gransch wrote:
I compile a programm using
ldmd -g -debug test.d
Then I try to debug using gdb with the D patches:
(gdb) list
1 ../sysdeps/x86_64/elf/start.S: No such file or directory.
in ../sysdeps/x86_64/elf/start.S
On x86-32 that gives me a listing of the main function defined in the D
runtime - but I am using a debug runtime. Does inserting a breakpoint in
your code and running to that work?
Christian Kamm schrieb:
On x86-32 that gives me a listing of the main function defined in the D
runtime -
On Arch Linux/32 (using the official ldc binary), list prints the source
code of the compiled file, just the way it's supposed to.
(gdb) list
1 import tango.io.Console;
2
3 int main(char[][] args)
4 {
5 for (int i = 0; i < args.length; i++)
6 {
7 Cout(args[i] ~ "\n");
8 }
9
10 return 0;
but I am using a debug runtime. Does inserting a breakpoint in
your code and running to that work?
Back on x86-64 again:
(gdb) break main
Breakpoint 1 at 0x409150
(gdb) run
Starting program: /home/timo/tmp/testd/test
[Thread debugging using libthread_db enabled]
[New Thread 0x7fb54f2456f0 (LWP 7001)]
[Switching to Thread 0x7fb54f2456f0 (LWP 7001)]
Breakpoint 1, 0x0000000000409150 in main ()
Current language: auto; currently asm
(gdb) step
Single stepping until exit from function main,
which has no line number information.
0x000000000040a830 in _STI_monitor_staticctor ()
(gdb) step
Single stepping until exit from function _STI_monitor_staticctor,
which has no line number information.
0x0000000000409183 in main ()
If I try to run list after that, the error message is different:
(gdb) list
1 /build/buildd/glibc-2.9/build-tree/amd64-libc/csu/crtn.S: No such file
or directory.
in /build/buildd/glibc-2.9/build-tree/amd64-libc/csu/crtn.S
Thanks and best regards,
Timo
Timo Gransch wrote:
Christian Kamm schrieb:
but I am using a debug runtime. Does inserting a breakpoint in
your code and running to that work?
Back on x86-64 again:
(gdb) break main
Breakpoint 1 at 0x409150
Since there's main and _Dmain and I don't know how the GDB patches interact
with breakpoint setting, can you try to make a breakpoint on the first line
of your D main function (i.e. b myfile.d:15) and run to that?
I'm now also subscribed to D.debugger and saw your post there. Let's move
the discussion.
Christian Kamm schrieb:
I'm now also subscribed to D.debugger and saw your post there. Let's move
the discussion.
I appended my answer to the existing thread 'Debugging LDC executables'.
Best regards,
Timo
Great news, happy to see x86_64 on the feature list :)
|
|
C & C++
DMDScript
Lutger <lutger.blijdestijn gmail.com> 