[SAoC] 'DPP with Linux kernel headers' Project Thread

Cristian Becerescu cristian.becerescu at yahoo.com
Mon Dec 2 21:36:33 UTC 2019


Update for week 2 of Milestone 3

- Fixed the bitfields issue 
(https://github.com/atilaneves/dpp/pull/219)
- Tested DPP with all the kernel headers included by Alex's 
driver + other 70 random kernel headers
- Discovered (what I hope to be the last) 5 issues

1. In some obscure parts of the kernel, there exists something 
like 'extern __visibile const void __nosave_begin;', which is a 
variable of type void (but declared extern, so the compiler 
doesn't complain). Still thinking about how DPP should translate 
this to valid D code.

2. Unknown enums in function return/param types won't generate 
opaque definitions for that enum (as it is the case for struct).

e.g.: enum A f(enum B); // A and B would be uknown identifiers
       struct C *f(struct D *); // C and D would be declared by 
default by DPP

3. Unreachable struct

e.g.:
// C
struct A {
     struct B {
         int a;
         int b;
     };
};

void f(struct B *); // valid in C

// D
void f(B *); // not valid in D, this is how DPP translates the 
function declaration
void f(A.B *); // OK, this should probably be the actual output

4. 'struct sockaddr size not known', and some functions return 
this struct type by value (not pointer to it). Definition of this 
struct should probably be there. Will check to see if I missed 
any flags in the Makefile.

> (3) I've tried using DPP with other kernel headers as well 
> (specifically netdevice.h), and usually I get an error telling 
> me the resources have been exhausted.

For this issue I previously proposed 2 approaches, which have 
their own limitations (thanks Atila for pointing them out).
The exhaustion of memory seems to happen while cpp/clang is still 
running, so the issue is not about the lines array (which anyway 
would not be bigger than MB, and the RAM usage is more than 6GB). 
I will, therefore, do some profiling to narrow down the causes 
for this and decide if there's something we could do about it.


More information about the Digitalmars-d mailing list