www.digitalmars.com         C & C++   DMDScript  

D.gnu - Newbie GDC issues

reply "Ramon" <spam thanks.no> writes:
On D's, and in particular GDC's, way to conquer the world there 
will evidently be many newbies to notice D, look at it, be drawn 
to it (and be happily trapped).

I am such a newbie and the idea behind this thread is to collect 
all the issues, quirks and nuisances a newbie might encounter.
Please note that quite typically this is not to do with GDC being 
at fault but rather with a newbie naturally not yet knowing all 
the ins and outs (like, e.g. that with GDC one must use "-fdebug" 
and not "-debug" as with dmd).

I assume that for most issues someone more experienced will step 
in and provide an explanation, a solution or a workaround or just 
some magic *g

So, here goes:

-------------

char[] someDynArray;

// in main, after someDynArray is somehow init'd...

      char c;
      for(int i = 0; i < someDynArray; i++)
         c = someDynArray[i];

Now, in the debugger:


 print someDynArray


// whatever it happens to hold. Works fine.


 print someDynArray[i]


Structure has no component named operator[].

Any ideas?
Sep 05 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Sep 06, 2013 at 01:49:17AM +0200, Ramon wrote:

 On D's, and in particular GDC's, way to conquer the world there will
 evidently be many newbies to notice D, look at it, be drawn to it
 (and be happily trapped).
 
 I am such a newbie and the idea behind this thread is to collect all
 the issues, quirks and nuisances a newbie might encounter.
 Please note that quite typically this is not to do with GDC being at
 fault but rather with a newbie naturally not yet knowing all the ins
 and outs (like, e.g. that with GDC one must use "-fdebug" and not
 "-debug" as with dmd).


Note that -fdebug isn't the only one you have to watch out for. A *lot*
of DMD options are renamed in GDC (mainly due to conflicts with GCC
native options). Most of them are just prepended with -f (like -debug =>
-fdebug) but there are some that are complete renames (like -D => -fdoc)
and syntax rewrites (-Dddocdir => -fdoc-dir=docdir).

The gdc manpage should be consulted when in doubt.



 I assume that for most issues someone more experienced will step in
 and provide an explanation, a solution or a workaround or just some
 magic *g
 
 So, here goes:
 
 -------------
 
 char[] someDynArray;
 
 // in main, after someDynArray is somehow init'd...
 
      char c;
      for(int i = 0; i < someDynArray; i++)
         c = someDynArray[i];
 
 Now, in the debugger:
 

print someDynArray


 // whatever it happens to hold. Works fine.
 

print someDynArray[i]


 Structure has no component named operator[].
 
 Any ideas?


Hmm. Maybe try someDynArray.ptr[i]? (Caveat: I never tried this before,
so dunno if it will work.)

 Iain: on that note, it looks like gdb thinks it's debugging C++, but D
doesn't have anything called 'operator[]'. It would be Really Nice if we
could somehow coax gdb to use opIndex instead (though it doesn't really
help in the case of dyn arrays 'cos they are built-in, and don't
actually have any opIndex to speak of).


T

-- 
Never step over a puddle, always step around it. Chances are that
whatever made it is still dripping.
Sep 05 2013
parent reply "Ramon" <spam thanks.no> writes:
On Thursday, 5 September 2013 at 23:58:06 UTC, H. S. Teoh wrote:

Thanks and


  Iain: on that note, it looks like gdb thinks it's debugging 
 C++, but D
 doesn't have anything called 'operator[]'. It would be Really 
 Nice if we
 could somehow coax gdb to use opIndex instead (though it 
 doesn't really
 help in the case of dyn arrays 'cos they are built-in, and don't
 actually have any opIndex to speak of).


I'm not so sure.

Observation:


 print someDynArray.length


10                               // works

char[5] cArray = "Hello";        // Let's try C like fixed length 
array


 print cArray[3]


'l'                              // works

I'm not that sure dyn arrays have no [] (or index or whatever 
it's called) operator. In the end they are just arrays with smart 
housekeeping behind the curtains and some methods (like "length").

I'm looking forward to hear and learn from Iain.

A+ -R
Sep 05 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Sep 06, 2013 at 02:59:30AM +0200, Ramon wrote:

 On Thursday, 5 September 2013 at 23:58:06 UTC, H. S. Teoh wrote:
 
 Thanks and
 

 Iain: on that note, it looks like gdb thinks it's debugging C++, but
D doesn't have anything called 'operator[]'. It would be Really Nice
if we could somehow coax gdb to use opIndex instead (though it
doesn't really help in the case of dyn arrays 'cos they are built-in,
and don't actually have any opIndex to speak of).


 
 I'm not so sure.
 
 Observation:
 

print someDynArray.length


 10                               // works
 
 char[5] cArray = "Hello";        // Let's try C like fixed length
 array
 

print cArray[3]


 'l'                              // works
 
 I'm not that sure dyn arrays have no [] (or index or whatever it's
 called) operator. In the end they are just arrays with smart
 housekeeping behind the curtains and some methods (like "length").


[...]

Actually, D arrays are implemented something like this:

	/* C code equivalent */
	struct int_array {
		int *ptr;
		size_t length;
	}

So if you do something like 'print someDynArray.ptr[4]' it should work.

Now obviously gdb does support more abstract array-like types, like C++
types that define operator[], so I was just saying that it would be nice
if we could figure out what to put in the debug data segment to make gdb
translate arr[i] in D into arr.ptr[i].

Static arrays in D are closer to C's stack-allocated arrays (e.g. if you
declare 'char localVar[10];' inside a function), so they more-or-less
work seamlessly with C array indexing notation.


T

-- 
I think Debian's doing something wrong, `apt-get install pesticide', doesn't
seem to remove the bugs on my system! -- Mike Dresser
Sep 05 2013
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 6 September 2013 01:59, Ramon <spam thanks.no> wrote:

 On Thursday, 5 September 2013 at 23:58:06 UTC, H. S. Teoh wrote:

 Thanks and



  Iain: on that note, it looks like gdb thinks it's debugging C++, but D
 doesn't have anything called 'operator[]'. It would be Really Nice if we
 could somehow coax gdb to use opIndex instead (though it doesn't really
 help in the case of dyn arrays 'cos they are built-in, and don't
 actually have any opIndex to speak of).



 I'm not so sure.

 Observation:


 print someDynArray.length


 10                               // works

 char[5] cArray = "Hello";        // Let's try C like fixed length array


 print cArray[3]


 'l'                              // works

 I'm not that sure dyn arrays have no [] (or index or whatever it's called)
 operator. In the end they are just arrays with smart housekeeping behind the
 curtains and some methods (like "length").

 I'm looking forward to hear and learn from Iain.


Dynamic arrays are just structs with a length and ptr field.  So when
you invoke '.length' in the debugger you aren't calling a method, you
are just retrieving the type's field value.

Currently, the only fancy thing the gdb does with D arrays is that it
pretty prints them. So take for example you have:

{ .length = 5, .ptr = "Hello" };


Rather than printing the dynamic array like the above, it does a
printf("%*.s") style operation to print the contents of .ptr, but only
as far as .length.  This is important because dynamic arrays are not
expected to be '0' terminated, and you can slice a dynamic array into
smaller arrays without copying data.


Having the ability to slice D arrays using [] in gdb is something on
my todo list when I get round to improving gdb for D.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 06 2013
parent reply "Ramon" <spam thanks.no> writes:
On Friday, 6 September 2013 at 07:02:56 UTC, Iain Buclaw wrote:

 Dynamic arrays are just structs with a length and ptr field.  
 So when
 you invoke '.length' in the debugger you aren't calling a 
 method, you
 are just retrieving the type's field value.

 Currently, the only fancy thing the gdb does with D arrays is 
 that it
 pretty prints them. So take for example you have:

 { .length = 5, .ptr = "Hello" };


 Rather than printing the dynamic array like the above, it does a
 printf("%*.s") style operation to print the contents of .ptr, 
 but only
 as far as .length.  This is important because dynamic arrays 
 are not
 expected to be '0' terminated, and you can slice a dynamic 
 array into
 smaller arrays without copying data.


 Having the ability to slice D arrays using [] in gdb is 
 something on
 my todo list when I get round to improving gdb for D.


Thanks for the explanation, Iain.

But: Doesn't that mean that myArray[] is just syntactic sugar for 
myArray.ptr[i]? And if so wouldn't it make sense to fool gdb, 
too, to accept print myArray[4] instead of myArray.ptr[4]?

Funnily btw. "p myArray" prints out the whole array, yet asking 
it to print out myArray[3] fails as described.

Thanks also to HS for his hints

A+ -R
Sep 06 2013
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 6 September 2013 08:34, Ramon <spam thanks.no> wrote:

 On Friday, 6 September 2013 at 07:02:56 UTC, Iain Buclaw wrote:

 Dynamic arrays are just structs with a length and ptr field.  So when
 you invoke '.length' in the debugger you aren't calling a method, you
 are just retrieving the type's field value.

 Currently, the only fancy thing the gdb does with D arrays is that it
 pretty prints them. So take for example you have:

 { .length = 5, .ptr = "Hello" };


 Rather than printing the dynamic array like the above, it does a
 printf("%*.s") style operation to print the contents of .ptr, but only
 as far as .length.  This is important because dynamic arrays are not
 expected to be '0' terminated, and you can slice a dynamic array into
 smaller arrays without copying data.


 Having the ability to slice D arrays using [] in gdb is something on
 my todo list when I get round to improving gdb for D.



 Thanks for the explanation, Iain.

 But: Doesn't that mean that myArray[] is just syntactic sugar for
 myArray.ptr[i]? And if so wouldn't it make sense to fool gdb, too, to accept
 print myArray[4] instead of myArray.ptr[4]?


Yes, myArray[] is just syntactical sugar.  What the compiler code
generates is myArray.ptr[i].

gdb will always accept myArray.ptr[4] because arrays are just structs.
 As I said, [] is something on my todo list.



 Funnily btw. "p myArray" prints out the whole array, yet asking it to print
 out myArray[3] fails as described.


As I said in my previous message, this is the only thing that gdb does
fancy with D arrays at this moment.  If you wrote the equivalent code
in C and called 'p myArray' in the debugger you'd get:

{ .length = 5, .ptr = "Hello12maybesomegarbageontheend" }


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 06 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 6 September 2013 00:56, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

  Iain: on that note, it looks like gdb thinks it's debugging C++, but D
 doesn't have anything called 'operator[]'. It would be Really Nice if we
 could somehow coax gdb to use opIndex instead (though it doesn't really
 help in the case of dyn arrays 'cos they are built-in, and don't
 actually have any opIndex to speak of).


It's using the D front-end of the gdb.  You'd know if gdb was trying
to debug it as C++, as it has a different error.

No symbol "operator[]" in current context.

The other error is generic and you can reproduce it when debugging C.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 05 2013
prev sibling parent reply "eles" <eles eles.com> writes:
On Thursday, 5 September 2013 at 23:49:18 UTC, Ramon wrote:

 On D's, and in particular GDC's, way to conquer the world there 
 will evidently be many newbies to notice D, look at it, be 
 drawn to it (and be happily trapped).

 I am such a newbie and the idea behind this thread is to 
 collect all the issues, quirks and nuisances a newbie might 
 encounter.


That being said, Iain, could you please update this example of 
yours:

http://iainbuclaw.wordpress.com/2010/05/22/writing-a-linux-kernel-module-in-d/

It is a very interesting concept, if it works...

Using the git head gdc I have these errors:

$make VERBOSE=1
gdc -c dinterface.d -o dinterface.o
make -C /lib/modules/3.11.0-5-generic/build 
M=/home/user/kernelmodule CONFIG_HELLO=m MAKE_KBUILD=1 modules
make[1]: Entering directory 
`/usr/src/linux-headers-3.11.0-5-generic'
   LD [M]  /home/user/kernelmodule/hello.o
   Building modules, stage 2.
   MODPOST 1 modules
WARNING: could not find /home/user/kernelmodule/.dinterface.o.cmd 
for /home/user/kernelmodule/dinterface.o
WARNING: "_D3std3utf12UTFException7__ClassZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: 
"_D3std4conv21ConvOverflowException6__ctorMFAyaAyamZC3std4conv21Co
vOverflowException" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: 
"_D6object9Exception6__ctorMFNaNbNfAyaAyamC6object9ThrowableZC9Exception" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_assert_msg" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_D3std5ascii7isDigitFNaNbNfwZb" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_arraycopy" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_D9Exception7__ClassZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: 
"_D3std3utf12UTFException6__ctorMFAyamAyamC6object9ThrowableZC3st
3utf12UTFException" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_newclass" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_D4core6memory2GC6qallocFNaNbmkZS4core6memory8BlkInfo_" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std4conv21ConvOverflowException7__ClassZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D12TypeInfo_Aya6__initZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std9exception7bailOutFNaNfAyamxAaZv" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std4conv13ConvException7__ClassZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_Dmodule_ref" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_d_newitemT" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_D4core6memory2GC6extendFNaNbPvmmZm" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D14TypeInfo_Array6__vtblZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std6format15FormatException7__ClassZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std6string9toStringzFNaNbAyaZPya" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: 
"_D3std4conv13ConvException6__ctorMFAyaAyamZC3std4conv13ConvException" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D15TypeInfo_Struct6__vtblZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_assert" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: 
"_D3std6format15FormatException6__ctorMFAyaAyamC6object9ThrowableZC3std6form
t15FormatException" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_Unwind_Resume" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_d_arrayappendT" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_D11TypeInfo_Aa6__initZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std4math7signbitFNaNbNeeZi" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std3utf6encodeFNaNfKG4awZm" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_arraycatnT" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_d_throw" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std3utf12isValidDcharFNaNbNfwZb" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_array_bounds" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_D16TypeInfo_Pointer6__vtblZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D14TypeInfo_Const6__vtblZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std6string12__ModuleInfoZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D10TypeInfo_a6__initZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_arraycatT" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_adDupT" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_arraysetcapacity" [/home/user/kernelmodule/hello.ko] 
undefined!
   CC      /home/user/kernelmodule/hello.mod.o
   LD [M]  /home/user/kernelmodule/hello.ko
make[1]: Leaving directory 
`/usr/src/linux-headers-3.11.0-5-generic'

Should the Makefile be updated to not link in libraries?
Sep 06 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 6 September 2013 08:32, eles <eles eles.com> wrote:

 On Thursday, 5 September 2013 at 23:49:18 UTC, Ramon wrote:

 On D's, and in particular GDC's, way to conquer the world there will
 evidently be many newbies to notice D, look at it, be drawn to it (and be
 happily trapped).

 I am such a newbie and the idea behind this thread is to collect all the
 issues, quirks and nuisances a newbie might encounter.



 That being said, Iain, could you please update this example of yours:

 http://iainbuclaw.wordpress.com/2010/05/22/writing-a-linux-kernel-module-in-d/

 It is a very interesting concept, if it works...

 Using the git head gdc I have these errors:

 $make VERBOSE=1
 gdc -c dinterface.d -o dinterface.o
 make -C /lib/modules/3.11.0-5-generic/build M=/home/user/kernelmodule
 CONFIG_HELLO=m MAKE_KBUILD=1 modules
 make[1]: Entering directory `/usr/src/linux-headers-3.11.0-5-generic'
   LD [M]  /home/user/kernelmodule/hello.o
   Building modules, stage 2.
   MODPOST 1 modules
 WARNING: could not find /home/user/kernelmodule/.dinterface.o.cmd for
 /home/user/kernelmodule/dinterface.o
 WARNING: "_D3std3utf12UTFException7__ClassZ"
 [/home/user/kernelmodule/hello.ko] undefined!
 WARNING:
 "_D3std4conv21ConvOverflowException6__ctorMFAyaAyamZC3std4conv21ConvOverflowException"
 [/home/user/kernelmodule/hello.ko] undefined!
 WARNING:
 "_D6object9Exception6__ctorMFNaNbNfAyaAyamC6object9ThrowableZC9Exception"
 [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_d_assert_msg" [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_D3std5ascii7isDigitFNaNbNfwZb" [/home/user/kernelmodule/hello.ko]
 undefined!
 WARNING: "_d_arraycopy" [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_D9Exception7__ClassZ" [/home/user/kernelmodule/hello.ko]
 undefined!
 WARNING:
 "_D3std3utf12UTFException6__ctorMFAyamAyamC6object9ThrowableZC3std3utf12UTFException"
 [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_d_newclass" [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_D4core6memory2GC6qallocFNaNbmkZS4core6memory8BlkInfo_"
 [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_D3std4conv21ConvOverflowException7__ClassZ"
 [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_D12TypeInfo_Aya6__initZ" [/home/user/kernelmodule/hello.ko]
 undefined!
 WARNING: "_D3std9exception7bailOutFNaNfAyamxAaZv"
 [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_D3std4conv13ConvException7__ClassZ"
 [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_Dmodule_ref" [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_d_newitemT" [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_D4core6memory2GC6extendFNaNbPvmmZm"
 [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_D14TypeInfo_Array6__vtblZ" [/home/user/kernelmodule/hello.ko]
 undefined!
 WARNING: "_D3std6format15FormatException7__ClassZ"
 [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_D3std6string9toStringzFNaNbAyaZPya"
 [/home/user/kernelmodule/hello.ko] undefined!
 WARNING:
 "_D3std4conv13ConvException6__ctorMFAyaAyamZC3std4conv13ConvException"
 [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_D15TypeInfo_Struct6__vtblZ" [/home/user/kernelmodule/hello.ko]
 undefined!
 WARNING: "_d_assert" [/home/user/kernelmodule/hello.ko] undefined!
 WARNING:
 "_D3std6format15FormatException6__ctorMFAyaAyamC6object9ThrowableZC3std6format15FormatException"
 [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_Unwind_Resume" [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_d_arrayappendT" [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_D11TypeInfo_Aa6__initZ" [/home/user/kernelmodule/hello.ko]
 undefined!
 WARNING: "_D3std4math7signbitFNaNbNeeZi" [/home/user/kernelmodule/hello.ko]
 undefined!
 WARNING: "_D3std3utf6encodeFNaNfKG4awZm" [/home/user/kernelmodule/hello.ko]
 undefined!
 WARNING: "_d_arraycatnT" [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_d_throw" [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_D3std3utf12isValidDcharFNaNbNfwZb"
 [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_d_array_bounds" [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_D16TypeInfo_Pointer6__vtblZ" [/home/user/kernelmodule/hello.ko]
 undefined!
 WARNING: "_D14TypeInfo_Const6__vtblZ" [/home/user/kernelmodule/hello.ko]
 undefined!
 WARNING: "_D3std6string12__ModuleInfoZ" [/home/user/kernelmodule/hello.ko]
 undefined!
 WARNING: "_D10TypeInfo_a6__initZ" [/home/user/kernelmodule/hello.ko]
 undefined!
 WARNING: "_d_arraycatT" [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_adDupT" [/home/user/kernelmodule/hello.ko] undefined!
 WARNING: "_d_arraysetcapacity" [/home/user/kernelmodule/hello.ko] undefined!
   CC      /home/user/kernelmodule/hello.mod.o
   LD [M]  /home/user/kernelmodule/hello.ko
 make[1]: Leaving directory `/usr/src/linux-headers-3.11.0-5-generic'

 Should the Makefile be updated to not link in libraries?


That's interesting, as gdc is only used to compile dinterface.o
(which has no reference to libphobos/druntime and shouldn't be
emitting references to it).

In today's gdc implementation (back then I believe that was for D1) -
you'd have to use -fno-emit-moduleinfo  (maybe I should reverse the
logic of that switch to make it easier to use).


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 06 2013
parent reply "eles" <eles eles.com> writes:
On Friday, 6 September 2013 at 07:55:39 UTC, Iain Buclaw wrote:

 On 6 September 2013 08:32, eles <eles eles.com> wrote:

 On Thursday, 5 September 2013 at 23:49:18 UTC, Ramon wrote:


 In today's gdc implementation (back then I believe that was for 
 D1) -
 you'd have to use -fno-emit-moduleinfo  (maybe I should reverse 
 the
 logic of that switch to make it easier to use).


Unfortunately, I still have the same errors, even with this:

gdc -fno-emit-moduleinfo -c dinterface.d -o dinterface.o

make -C /lib/modules/3.11.0-5-generic/build 
M=/home/user/kernelmodule CONFIG_HELLO=m MAKE_KBUILD=1 modules

OTOH, could you enlighten me why the kernel make complains about:

WARNING: could not find /home/user/kernelmodule/.dinterface.o.cmd 
for /home/user/kernelmodule/dinterface.o

Who's supposed to generate that file?

Thanks

PS: below, the full list of errors (on Linux 64):
$make VERBOSE=1
gdc -fno-emit-moduleinfo -c dinterface.d -o dinterface.o
make -C /lib/modules/3.11.0-5-generic/build 
M=/home/user/kernelmodule CONFIG_HELLO=m MAKE_KBUILD=1 modules
make[1]: Entering directory 
`/usr/src/linux-headers-3.11.0-5-generic'
   LD [M]  /home/user/kernelmodule/hello.o
   Building modules, stage 2.
   MODPOST 1 modules
WARNING: could not find /home/user/kernelmodule/.dinterface.o.cmd 
for /home/user/kernelmodule/dinterface.o
WARNING: "_D3std3utf12UTFException7__ClassZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: 
"_D3std4conv21ConvOverflowException6__ctorMFAyaAyamZC3std4conv21Co
vOverflowException" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: 
"_D6object9Exception6__ctorMFNaNbNfAyaAyamC6object9ThrowableZC9Exception" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_assert_msg" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_D3std5ascii7isDigitFNaNbNfwZb" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_arraycopy" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_D9Exception7__ClassZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: 
"_D3std3utf12UTFException6__ctorMFAyamAyamC6object9ThrowableZC3st
3utf12UTFException" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_newclass" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_D4core6memory2GC6qallocFNaNbmkZS4core6memory8BlkInfo_" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std4conv21ConvOverflowException7__ClassZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D12TypeInfo_Aya6__initZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std9exception7bailOutFNaNfAyamxAaZv" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std4conv13ConvException7__ClassZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_newitemT" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_D4core6memory2GC6extendFNaNbPvmmZm" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D14TypeInfo_Array6__vtblZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std6format15FormatException7__ClassZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std6string9toStringzFNaNbAyaZPya" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: 
"_D3std4conv13ConvException6__ctorMFAyaAyamZC3std4conv13ConvException" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D15TypeInfo_Struct6__vtblZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_assert" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: 
"_D3std6format15FormatException6__ctorMFAyaAyamC6object9ThrowableZC3std6form
t15FormatException" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_Unwind_Resume" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_d_arrayappendT" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_D11TypeInfo_Aa6__initZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std4math7signbitFNaNbNeeZi" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std3utf6encodeFNaNfKG4awZm" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_arraycatnT" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_d_throw" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std3utf12isValidDcharFNaNbNfwZb" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_array_bounds" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_D16TypeInfo_Pointer6__vtblZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D14TypeInfo_Const6__vtblZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D10TypeInfo_a6__initZ" 
[/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_arraycatT" [/home/user/kernelmodule/hello.ko] 
undefined!
WARNING: "_adDupT" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_arraysetcapacity" [/home/user/kernelmodule/hello.ko] 
undefined!
   CC      /home/user/kernelmodule/hello.mod.o
   LD [M]  /home/user/kernelmodule/hello.ko
make[1]: Leaving directory 
`/usr/src/linux-headers-3.11.0-5-generic'
Sep 06 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 6 September 2013 10:15, eles <eles eles.com> wrote:

 On Friday, 6 September 2013 at 07:55:39 UTC, Iain Buclaw wrote:

 On 6 September 2013 08:32, eles <eles eles.com> wrote:

 On Thursday, 5 September 2013 at 23:49:18 UTC, Ramon wrote:


 In today's gdc implementation (back then I believe that was for D1) -
 you'd have to use -fno-emit-moduleinfo  (maybe I should reverse the
 logic of that switch to make it easier to use).



 Unfortunately, I still have the same errors, even with this:

 gdc -fno-emit-moduleinfo -c dinterface.d -o dinterface.o


 make -C /lib/modules/3.11.0-5-generic/build M=/home/user/kernelmodule
 CONFIG_HELLO=m MAKE_KBUILD=1 modules

 OTOH, could you enlighten me why the kernel make complains about:


 WARNING: could not find /home/user/kernelmodule/.dinterface.o.cmd for
 /home/user/kernelmodule/dinterface.o

 Who's supposed to generate that file?

 Thanks

 PS: below, the full list of errors (on Linux 64):
 $make VERBOSE=1
 gdc -fno-emit-moduleinfo -c dinterface.d -o dinterface.o


I'll have to give it a try when 2.064 is out.  It has some nice fixes
that makes things easier to link D compiled code against C/C++
programs  (I've got a mini-project that I intend to show off at some
point)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 06 2013
parent "eles" <eles eles.com> writes:
On Friday, 6 September 2013 at 10:35:15 UTC, Iain Buclaw wrote:

 On 6 September 2013 10:15, eles <eles eles.com> wrote:

 On Friday, 6 September 2013 at 07:55:39 UTC, Iain Buclaw wrote:

 On 6 September 2013 08:32, eles <eles eles.com> wrote:

 On Thursday, 5 September 2013 at 23:49:18 UTC, Ramon wrote:






 I'll have to give it a try when 2.064 is out.  It has some nice 
 fixes
 that makes things easier to link D compiled code against C/C++
 programs  (I've got a mini-project that I intend to show off at 
 some
 point)


OK. Thank you for that. I look forward for the 2.064 release and 
gdc integration.

Thank you for all the good work.
Sep 06 2013