1 --- 2 title: 'SAOC LLDB D integration: 9th Weekly Update' 3 date: '2021-11-18T18:02:00+01:00' 4 tags: ['saoc', 'saoc2021', 'dlang', 'llvm', 'lldb', 'debug', 'debugging', 'dwarf'] 5 description: "This post describes what I've done on the 9th week of the 6 Symmetry Autumn of Code 2021, including follow up updates on the LLVM patches 7 and some fixed issues." 8 --- 9 10 Hi D community! 11 12 I'm here again, to describe what I've done during the ninth week of Symmetry 13 Autumn of Code. 14 15 ## LLVM upstream follow up update 16 17 I started this week updating the rest of the patches to reflect the suggestions 18 made in the first patch, such as use a different OutputBuffer and other nit 19 codestyle changes. It turns out to be very unproductive week, unfortunately, 20 since I got some runtime errors such as heap buffer overflows and heap usage 21 after free() calls leading to very weird bugs because of my dumb idea of 22 refactoring the existing code. 23 24 TL;DR of the situation, I made a vim macro to substitute the existing 25 OutputString to an OutputBuffer and, since comma expressions are a thing, 26 situations like `buffer.append(ptr, size);` got silently translated to `buffer 27 << ptr, size;`. Since I preallocated the buffer, the segfaults were 28 intermittent. Furthermore, the semantics of my previous Free() method included 29 resetting the buffer after a free(), leading to some heap usage after free(). 30 31 Anyway, you can check the changes I've made 32 [here](https://github.com/ljmf00/llvm-project/tree/add-d-demangler-splitted). 33 34 ## Fixed issues 35 36 ### Generate artificial tag on generated main files 37 38 DWARF now generates an artificial tag when `-main` argument is passed 39 indicating that the symbol is generated by the compiler. The change can be 40 found [here](https://github.com/dlang/dmd/pull/13301). In the meanwhile, I 41 accidentally found and [fixed](https://github.com/dlang/dmd/pull/13302) a 42 pre-release regression caused by the OutBuffer move when testing this. 43 44 ### Associative arrays are now named with its qualified type name 45 46 Instead of printing `_AArray_<key>_<value>` where `<key>` and `<value>` is the 47 string representation of the TY, we now have the type name we are used to 48 `<value>[<key>]`. This also eliminates the problem where fake TY types are 49 internally used -- e.g. `string` types are faked to `ucent` types. You can see 50 the change [here](https://github.com/dlang/dmd/pull/13296) and the [associated 51 issue](https://issues.dlang.org/show_bug.cgi?id=22508). 52 53 ### Attempt to fix the calling convention 54 55 I dug into the backend codegen to understand a bit more about how the calling 56 convention is currently being processed. I ended up with a working test 57 although very weird errors are happening and I cannot have a reduced 58 reproducible test case to locally understand the problem and go forward with 59 this, although Martin Kinkelin suggested something that I can start with. You 60 can find the WIP PR [here](https://github.com/dlang/dmd/pull/13287). 61 62 ### Other reported issues 63 64 On LDC I found out that the compiler always generates the DWARF visibility 65 attributes, even if not necessary, leading to bigger binary sizes. I created an 66 [issue](https://github.com/ldc-developers/ldc/issues/3870) about that. 67 68 ## What is next? 69 70 I ended up not starting the TypeSystem nor DWARFFASTParser implementation. I 71 will try to hopefully go forward with it next week. 72 73 You can also read this on the D programming language forum, 74 [here](https://email@example.com), 75 and discuss there. 76 77 Read about the [previous week](../d-saoc-2021-08/) and [next 78 week](../d-saoc-2021-10/).