Re: D code obfuscator
On 14/06/18 08:21, DigitalDesigns wrote: On Thursday, 14 June 2018 at 02:13:58 UTC, Shachar Shemesh wrote: With that said, what you're trying to achieve is probably not a good idea anyways. With very few exceptions(1), reverse-engineering code to figure out what it does is not considerably more difficult than using the source, even when none of the identifiers leak at all. Certain aspects of creating attacks are even easier with good rev-eng tools than in source form. Shachar Just one question! Are you kidding me? First of all, run your program under strace. For a surprising percentage of the programs that should give you a fairly good idea of what the program is doing. ltrace goes further, but it can be easily defeated by statically linking, so probably irrelevant for our current discussion. Next, try loading your program in Ida Pro (https://www.hex-rays.com/products/ida/index.shtml). You will notice that program flow practically jumps out at you with no further work on your part. Other tricks require a little more knowledge, but are still exceedingly effective. In a demonstration I saw in 2002, Halvar Flake showed how he uses Ida to graph the branches, and then use a tool he built to place breakpoints on the branch points. Next he started feeding inputs to the program, and colored the graph where the input sent the code. He used that to find the correct input that would bring the code path to the line he thought might be vulnerable. If I had to do this trick today for *my own* programs, I'd still use Ida and the compiled code. So, no, I was not kidding. Not even close. Shachar
To the D Foundation Moderators
The problem with the D Foundations' new approach to 'moderating' is: Who does the moderating? Who long does it take? What exactly are these so called 'moderator' 'filtering', so that others cannot see it? Without complete insight into this new model of moderating posts, then this is just a tool for abuse. Anything can be 'moderated'. In which case, these forums become the D Foundations propaganda machine.
Re: D code obfuscator
On Thursday, 14 June 2018 at 08:54:16 UTC, Shachar Shemesh wrote: On 14/06/18 08:21, DigitalDesigns wrote: On Thursday, 14 June 2018 at 02:13:58 UTC, Shachar Shemesh wrote: With that said, what you're trying to achieve is probably not a good idea anyways. With very few exceptions(1), reverse-engineering code to figure out what it does is not considerably more difficult than using the source, even when none of the identifiers leak at all. Certain aspects of creating attacks are even easier with good rev-eng tools than in source form. Shachar Just one question! Are you kidding me? First of all, run your program under strace. For a surprising percentage of the programs that should give you a fairly good idea of what the program is doing. ltrace goes further, but it can be easily defeated by statically linking, so probably irrelevant for our current discussion. Next, try loading your program in Ida Pro (https://www.hex-rays.com/products/ida/index.shtml). You will notice that program flow practically jumps out at you with no further work on your part. Other tricks require a little more knowledge, but are still exceedingly effective. In a demonstration I saw in 2002, Halvar Flake showed how he uses Ida to graph the branches, and then use a tool he built to place breakpoints on the branch points. Next he started feeding inputs to the program, and colored the graph where the input sent the code. He used that to find the correct input that would bring the code path to the line he thought might be vulnerable. If I had to do this trick today for *my own* programs, I'd still use Ida and the compiled code. So, no, I was not kidding. Not even close. Shachar Wait? Are you sure you are not kidding? Do you want another shot?
Re: D code obfuscator
On 14/06/18 13:39, DigitalDesigns wrote: Wait? Are you sure you are not kidding? Do you want another shot? No, I'm fine. Thank you. I am not out here to convert anyone. If you want to believe the magic of obfuscation, go right ahead. You can probably even leverage D's CTFE to do it inside the compiler while not making your program too much uglier. Something like replacing definitions with: mixin Obfuscate!(int, "variableName"); and use with: Deobfuscate!"variableName"; Shouldn't be too difficult to create. Shachar
Re: D code obfuscator
On Thursday, 14 June 2018 at 11:07:17 UTC, Shachar Shemesh wrote: On 14/06/18 13:39, DigitalDesigns wrote: Wait? Are you sure you are not kidding? Do you want another shot? No, I'm fine. Thank you. I am not out here to convert anyone. If you want to believe the magic of obfuscation, go right ahead. Dude, don't be an idiot! Please! Of course, here we go... You can probably even leverage D's CTFE to do it inside the compiler while not making your program too much uglier. Something like replacing definitions with: mixin Obfuscate!(int, "variableName"); and use with: Deobfuscate!"variableName"; Shouldn't be too difficult to create. That's the best you can do? Do you really expect me to go and manually obfuscate an entire program? Do you want to try again? 3 strikes and your out!
Would be nice if compiler gave more information!
object.Error@(0): Access Violation
0x00415999
0x0040A3B7
0x00518A2D
0x005751FD
0x005ABA41
0x005ABAEB
0x00525136
0x005246D6
0x005253E2
0x0066509D
0x00664F38
0x00529F68
0x77018744 in BaseThreadInitThunk
0x77C5582D in RtlGetAppContainerNamedObjectPath
0x77C557FD in RtlGetAppContainerNamedObjectPath
So, when the compiler crashes it would be really nice if more
information than just the above was given!
All I know is that using the code
static foreach(a; ["wchar", "ushort"])
mixin("void bar("~a~" value) { foo(); }");
is what is causing it. Manually giving the functions works fine.
Re: D code obfuscator
On Thursday, 14 June 2018 at 08:54:16 UTC, Shachar Shemesh wrote: So, no, I was not kidding. Not even close. I've had some experience on both sides of this... so, I think I can say with some certainty that debugging symbols make reverse-engineering MUCH easier (many hunts to find the relevant code can be reduced to a keyword search), so I think it's a valid concern. That D leaks identifiers and other bits from the source code is a real issue preventing some real-world use cases. E.g., there might be legal obligations in place where leaking source code identifiers could be considered a breach of NDA etc. In one case, we needed to write an RTTI patcher for C++ (MSVC) after updating/reconfiguring the build toolchain, as the compiler would otherwise place the class names of some classes in the binary.
Re: Would be nice if compiler gave more information!
On Thursday, 14 June 2018 at 11:30:46 UTC, DigitalDesigns wrote: object.Error@(0): Access Violation 0x00415999 0x0040A3B7 0x00518A2D 0x005751FD 0x005ABA41 0x005ABAEB 0x00525136 0x005246D6 0x005253E2 0x0066509D 0x00664F38 0x00529F68 0x77018744 in BaseThreadInitThunk 0x77C5582D in RtlGetAppContainerNamedObjectPath 0x77C557FD in RtlGetAppContainerNamedObjectPath So, when the compiler crashes it would be really nice if more information than just the above was given! Make sure you are building with -g (debug information).
Re: Would be nice if compiler gave more information!
On 14.06.2018 13:30, DigitalDesigns wrote:
All I know is that using the code
static foreach(a; ["wchar", "ushort"])
mixin("void bar("~a~" value) { foo(); }");
is what is causing it. Manually giving the functions works fine.
This works:
void foo(){}
static foreach(a; ["wchar", "ushort"])
mixin("void bar("~a~" value) { foo(); }");
If you can give a code snippet that causes the crash, I can probably
figure out what's going wrong.
Re: Would be nice if compiler gave more information!
On Thursday, 14 June 2018 at 11:30:46 UTC, DigitalDesigns wrote:
object.Error@(0): Access Violation
0x00415999
0x0040A3B7
0x00518A2D
0x005751FD
0x005ABA41
0x005ABAEB
0x00525136
0x005246D6
0x005253E2
0x0066509D
0x00664F38
0x00529F68
0x77018744 in BaseThreadInitThunk
0x77C5582D in RtlGetAppContainerNamedObjectPath
0x77C557FD in RtlGetAppContainerNamedObjectPath
So, when the compiler crashes it would be really nice if more
information than just the above was given!
All I know is that using the code
static foreach(a; ["wchar", "ushort"])
mixin("void bar("~a~" value) { foo(); }");
is what is causing it. Manually giving the functions works fine.
That code works great when I define foo, and doesn't crash when I
don't. Please provide a full example that causes the crash so
that we can figure out the cause.
Now, since this is a compiler crash, getting symbols in the stack
trace isn't going to help you unless you're planning to fix the
compiler itself. If you are, just follow Vlad's advice and build
the compiler with -g.
On Thursday, 14 June 2018 at 11:55:03 UTC, Vladimir Panteleev
wrote:
Make sure you are building with -g (debug information).
This is from the compiler crashing. I doubt he's built that.
--
Simen
Re: Safe and performant actor model in D
On Wednesday, 13 June 2018 at 09:45:04 UTC, Per Nordlöw wrote: I've read up on Pony [1] and realized that it currently has a superior implementation of the actor model when it comes to combining safety, efficiency and memory management determinism (thread-local reference-counting GC with consensus guarantees) What libraries do we have at our disposal in D (including code.dlang.org) for implementing task-based parallelism that is close to Pony's solution with regards to 1. @safely sending isolated (transitively unique reference to) messages between actors (tasks) without the need for copying. Vibe.d has, for instance, `makeIsolated` [2] that serves this purpose. 2. a task-scheduler that can move blocked tasks between threads. Yes, I know, this has been discussed many times before...I'm checking to see if there are any updates. 3. could we make such a solution GC-free by requiring immutable data inside isolated messages to be unique references (not currently implicitly shared) aswell using, for instance, https://dlang.org/library/std/typecons/unique.html. I'm thinking of a trait named something like `makeIsolatedUnshared` that checks these restrictions. [1] https://www.ponylang.org/ [2] http://vibed.org/api/vibe.core.concurrency/makeIsolated What assistance can/could we currently/in-the-future get from D's type-system to verify correctness of these paradigms? I'm working on a library to allow @safe sharing between threads. Originally I was just trying to write a D version of Rust's std::sync::Mutex. It's so alpha it's not even in the dub registry yet: https://github.com/atilaneves/fearless The idea is to have a @safe wrapper so the user doesn't have to work with `shared` directly (which I call "Bring Your Own Mutex"). I've been giving some thought to isolated data - it really annoys in me in D that I can't send mutable data to another threads unless I make it `shared`, even though I just created it and will never see it again from this or any other thread! I need to think about how to do isolated properly. I'll look at vibe.d for inspiration. Atila
Re: Safe and performant actor model in D
On Thursday, 14 June 2018 at 13:24:06 UTC, Atila Neves wrote: [snip] I need to think about how to do isolated properly. I'll look at vibe.d for inspiration. I took a look at it yesterday, but the class version depended on a long mixin that I didn't feel like fully examining... I did notice that vibe.d's Isolated can be used both safely and unsafely though.
Re: D code obfuscator
On Thursday, 14 June 2018 at 10:39:19 UTC, DigitalDesigns wrote: Wait? Are you sure you are not kidding? Do you want another shot? I won't say that obfuscation is entirely useless, if I have to choose I'll of course take the version with symbols for reverse engineering and there are specific cases where symbols carry way to much information for you to want it disclosed (most common being names of customers or projects etc). But, as someone whose job is to find security issues with softwares (and other stuff) be it with or without source, I can say with professionnal certainty that things like changing all identifiers to single-letter ids don't slow me the slightest in my assignments. That's just the state of things, reversers deal with stripped stuff all the time, identifiers are just nice to have. So instead, here's what would slow a reverse engineer: - Remove strings. Make sure to remove as many as you can, especially debug statements. Hide the rest by encrypting in memory. Even if it is possible to decrypt it or read it at runtime it'll be way harder to correlate things together. - Pack. Have your software decipher itself in memory at runtime, not all at once but only sections at once dynamically. Use random keys automatically generated at compile-time for that, that'll mess up binary diffs. - Include binary tricks to mess up with disassemblers. There are many constructs that common disassemblers interpret badly. - Mess with the structure. If you can remove all conditions and loops. A reverser can often just look at a function's logical graph and know what kind of work it is doing. The movfuscator is a good example. - Add runtime checks based on time deltas between two points of the code in different functions. Generate other output based on that. - Be sure to encrypt all communications of course. In short, do what good malwares do.
Re: D code obfuscator
On 06/14/2018 04:33 AM, DigitalDesigns wrote: > 3 strikes and > your out! That was your third. :/ Ali
Re: Why are we not using libbacktrace for backtrace?
Am Thu, 14 Jun 2018 01:19:30 + schrieb Yuxuan Shui: > Just ran into a problem where program will crash during stack trace. > Turns out not only does druntime not support compressed debug info, it > cannot handle it at all. > > So I was thinking why don't we use a existing and proven library for > this, instead of roll our own? GDC uses libbacktrace since 2013: https://github.com/D-Programming-GDC/ GDC/blob/master/libphobos/libdruntime/gcc/backtrace.d I think the main problem for DMD/LDC is that libbacktrace is not an installed library, it's only available while building GCC. -- Johannes
Re: How To Make an RSS Feed from a Forum Thread
On Thursday, 14 June 2018 at 03:17:37 UTC, nathanjame wrote: We spend a lot of our online time in an RSS reader, but not everything we want to follow has an RSS feed. There are web apps to monitor pages for changes, but forum threads spill over onto many pages – how can you get an RSS feed for a specific thread? On forum.dlang.org, you can do it as follows: 1. Log in or register an account. 2. On the first post of the forum thread, click the "Subscribe" link. 3. Submit the form to create the subscription. 4. Click "Get ATOM feed" in the row of the newly created subscription.
Re: Safe and performant actor model in D
On Thursday, 14 June 2018 at 13:24:06 UTC, Atila Neves wrote: I need to think about how to do isolated properly. I'll look at vibe.d for inspiration. Thanks. I'll have a look when you have something working.
Re: To the D Foundation Moderators
On 6/14/18 11:02 AM, Duser wrote: The problem with the D Foundations' new approach to 'moderating' is: Who does the moderating? Thanks for asking. Moderation is done by a small leadership group of which Walter and I are part. I won't name other names for the simple reason I forgot who the others are. Who long does it take? It's done on a best effort basis. Vladimir created a nice automated system that only flags a small number of posts for moderation, I'm sure he'd be glad to share details. What exactly are these so called 'moderator' 'filtering', so that others cannot see it? Without complete insight into this new model of moderating posts, then this is just a tool for abuse. Anything can be 'moderated'. In which case, these forums become the D Foundations propaganda machine. This is not a corporation that needs formal rules lest whatever CEO gets on board can abuse position. Also, it's not a mission-driven free speech platform where you have defined rights just by posting. That said, the sheer notion that Walter or myself would moderate away posts of which technical content disagree with is ridiculous. If you're trying to put a political spin on this, please leave this community. Andrei
Re: Why are we not using libbacktrace for backtrace?
On Thursday, 14 June 2018 at 17:26:50 UTC, Johannes Pfau wrote: Am Thu, 14 Jun 2018 01:19:30 + schrieb Yuxuan Shui: Just ran into a problem where program will crash during stack trace. Turns out not only does druntime not support compressed debug info, it cannot handle it at all. So I was thinking why don't we use a existing and proven library for this, instead of roll our own? GDC uses libbacktrace since 2013: https://github.com/D-Programming-GDC/ GDC/blob/master/libphobos/libdruntime/gcc/backtrace.d I think the main problem for DMD/LDC is that libbacktrace is not an installed library, it's only available while building GCC. libbacktrace is a standalone library: https://github.com/ianlancetaylor/libbacktrace GCC is using it.
Re: Would be nice if compiler gave more information!
On Thursday, 14 June 2018 at 12:12:34 UTC, Timon Gehr wrote:
On 14.06.2018 13:30, DigitalDesigns wrote:
All I know is that using the code
static foreach(a; ["wchar", "ushort"])
mixin("void bar("~a~" value) { foo(); }");
is what is causing it. Manually giving the functions works
fine.
This works:
void foo(){}
static foreach(a; ["wchar", "ushort"])
mixin("void bar("~a~" value) { foo(); }");
If you can give a code snippet that causes the crash, I can
probably figure out what's going wrong.
I can't because I have no idea what causes it. I changed the
mixin to not use the foreach but a CTFE that generates a string
using the foreach which is then mixed in.
Why can't the compiler give a stack trace? Any information is
better than none!
I am getting the compiler to crash from a different problem after
I moved some files around. I have no idea where the error is now.
Why not ship with a debuggable dmd so that when it crashes it can
be debugged and potentially fixed but at least see where it might
be crashing.
Re: Would be nice if compiler gave more information!
I am getting the compiler to crash from a different problem after I moved some files around. I have no idea where the error is now. There was a module that was included that was crashing the compiler for some reason. When I removed it, which wasn't part of the original project the compiler didn't crash. So, this is either a bug in modules or something in the module that crashed. the two modules I removed were sumtype and openmethods... both public.
Re: Would be nice if compiler gave more information!
On Friday, June 15, 2018 02:31:49 DigitalDesigns via Digitalmars-d wrote: > > I am getting the compiler to crash from a different problem > > after I moved some files around. I have no idea where the error > > is now. > > There was a module that was included that was crashing the > compiler for some reason. When I removed it, which wasn't part of > the original project the compiler didn't crash. > > So, this is either a bug in modules or something in the module > that crashed. > > the two modules I removed were sumtype and openmethods... both > public. Regardless of whether there's a bug in any of the modules that you're using, the compiler should never crash. If it does, there's a bug in the compiler. - Jonathan M Davis
Re: Would be nice if compiler gave more information!
On Friday, June 15, 2018 02:19:51 DigitalDesigns via Digitalmars-d wrote: > Why can't the compiler give a stack trace? Any information is > better than none! It's not giving a stack trace with symbol names, because it wasn't compiled with debug symbols enabled. - Jonathan M Davis
Re: Would be nice if compiler gave more information!
On Friday, 15 June 2018 at 02:47:56 UTC, Jonathan M Davis wrote: On Friday, June 15, 2018 02:31:49 DigitalDesigns via Digitalmars-d wrote: > I am getting the compiler to crash from a different problem > after I moved some files around. I have no idea where the > error is now. There was a module that was included that was crashing the compiler for some reason. When I removed it, which wasn't part of the original project the compiler didn't crash. So, this is either a bug in modules or something in the module that crashed. the two modules I removed were sumtype and openmethods... both public. Regardless of whether there's a bug in any of the modules that you're using, the compiler should never crash. If it does, there's a bug in the compiler. - Jonathan M Davis I know, but without having any type of feedback it becomes extremely difficult to find the code to figure out what is going on. I only was lucky to find the module issue relatively quickly because I just added a bunch of modules and it was working right before. If I would have not built the code right after or would have not tried to figure out what was going on then it would become a harder problem. Considering that some code I added before also asserted would have lead me to think it was related to that problem and not simply including a module. So, it should be very important to have some type of info that connects the error to what the compiler was doing. With large problems it is not easy to reduce to a test case that shows the problem directly. I think a debug build dmd would be the easiest way. It is built with the release version so they are identical... but it would help users to quickly help with compiler errors rather than having to go build the compiler themselves, etc.
Re: Would be nice if compiler gave more information!
On Friday, June 15, 2018 03:54:34 DigitalDesigns via Digitalmars-d wrote: > On Friday, 15 June 2018 at 02:47:56 UTC, Jonathan M Davis wrote: > > On Friday, June 15, 2018 02:31:49 DigitalDesigns via > > > > Digitalmars-d wrote: > >> > I am getting the compiler to crash from a different problem > >> > after I moved some files around. I have no idea where the > >> > error is now. > >> > >> There was a module that was included that was crashing the > >> compiler for some reason. When I removed it, which wasn't part > >> of the original project the compiler didn't crash. > >> > >> So, this is either a bug in modules or something in the module > >> that crashed. > >> > >> the two modules I removed were sumtype and openmethods... both > >> public. > > > > Regardless of whether there's a bug in any of the modules that > > you're using, the compiler should never crash. If it does, > > there's a bug in the compiler. > > > > - Jonathan M Davis > > I know, but without having any type of feedback it becomes > extremely difficult to find the code to figure out what is going > on. I only was lucky to find the module issue relatively quickly > because I just added a bunch of modules and it was working right > before. If I would have not built the code right after or would > have not tried to figure out what was going on then it would > become a harder problem. Considering that some code I added > before also asserted would have lead me to think it was related > to that problem and not simply including a module. > > So, it should be very important to have some type of info that > connects the error to what the compiler was doing. With large > problems it is not easy to reduce to a test case that shows the > problem directly. > > I think a debug build dmd would be the easiest way. It is built > with the release version so they are identical... but it would > help users to quickly help with compiler errors rather than > having to go build the compiler themselves, etc. I'm not against there being an easy way to get at a debug build of the compiler without building it yourself, but really, compiler errors shouldn't be happening often enough for it to matter much. And in most cases, the people who first run into the problem aren't the ones who end up debugging it anyway. Regardless, if you haven't yet, I'd suggest using dustmite to reduce the problem: https://github.com/CyberShadow/DustMite/wiki - Jonathan M Davis
Re: Would be nice if compiler gave more information!
On Friday, 15 June 2018 at 03:54:34 UTC, DigitalDesigns wrote: So, it should be very important to have some type of info that connects the error to what the compiler was doing. With large problems it is not easy to reduce to a test case that shows the problem directly. In my experience as a layman as far as DMD internals go, a compiler stack trace generally does little to elucidate what the cause of the crash is, or especially what part of the program is responsible. Tools to reduce the input (DustMite, or Digger for regressions) are generally more effective. I think a debug build dmd would be the easiest way. It is built with the release version so they are identical... but it would help users to quickly help with compiler errors rather than having to go build the compiler themselves, etc. FWIW, Digger can build debug DMD binaries with `-c build.components.dmd.debugDMD=true`.
Re: IOS support status
On Wednesday, 13 June 2018 at 02:33:22 UTC, Joakim wrote: On Wednesday, 13 June 2018 at 02:18:55 UTC, makedgreatagain wrote: When I cherry pick the commit 08041422, git report the IOS branch dose not have function `getCAssertFunctionName` , `DtoCAssert` there seems missing some old commit from IOS branch to ltsmaster branch. I don't know how many and how to compare to get all the missing commit to work. Thanks for you help again. Are you starting from the top, with the oldest commit first? Because the older commits supply those functions. You may not want to cherry-pick if you're not used to doing it, and just apply the patch itself: https://patch-diff.githubusercontent.com/raw/ldc-developers/ldc/pull/2748.diff I has try a lot diff way, none of them work. to apply this patch it should this error: error: patch failed: driver/main.cpp:860 error: driver/main.cpp: patch does not apply error: patch failed: gen/module.cpp:743 error: gen/module.cpp: patch does not apply
Re: IOS support status
On Friday, 15 June 2018 at 05:26:57 UTC, makedgreatagain wrote: On Wednesday, 13 June 2018 at 02:33:22 UTC, Joakim wrote: On Wednesday, 13 June 2018 at 02:18:55 UTC, makedgreatagain wrote: When I cherry pick the commit 08041422, git report the IOS branch dose not have function `getCAssertFunctionName` , `DtoCAssert` there seems missing some old commit from IOS branch to ltsmaster branch. I don't know how many and how to compare to get all the missing commit to work. Thanks for you help again. Are you starting from the top, with the oldest commit first? Because the older commits supply those functions. You may not want to cherry-pick if you're not used to doing it, and just apply the patch itself: https://patch-diff.githubusercontent.com/raw/ldc-developers/ldc/pull/2748.diff I has try a lot diff way, none of them work. to apply this patch it should this error: error: patch failed: driver/main.cpp:860 error: driver/main.cpp: patch does not apply error: patch failed: gen/module.cpp:743 error: gen/module.cpp: patch does not apply I use git apply --reject --whitespace=fix to patch and it working now. but I can not build the llvm use Dan Olson script or cmake, it report error. (I can build new llvm without problem, but after I add some patch or merge it will break) : command not found/apple/ldc-iphone-dev/llvm/autoconf/config.guess: line 6: : command not found/apple/ldc-iphone-dev/llvm/autoconf/config.guess: line 8: : command not found/apple/ldc-iphone-dev/llvm/autoconf/config.guess: line 28: : command not found/apple/ldc-iphone-dev/llvm/autoconf/config.guess: line 29: : command not found/apple/ldc-iphone-dev/llvm/autoconf/config.guess: line 40: : command not found/apple/ldc-iphone-dev/llvm/autoconf/config.guess: line 42: : command not found/apple/ldc-iphone-dev/llvm/autoconf/config.guess: line 54: : command not found/apple/ldc-iphone-dev/llvm/autoconf/config.guess: line 65: : command not found/apple/ldc-iphone-dev/llvm/autoconf/config.guess: line 68: 'var/root/.projects/apple/ldc-iphone-dev/llvm/autoconf/config.guess: line 71: syntax error near unexpected token `in 'var/root/.projects/apple/ldc-iphone-dev/llvm/autoconf/config.guess: line 71: ` case $1 in CMake Error at cmake/modules/GetHostTriple.cmake:24 (message): Failed to execute /var/root/.projects/apple/ldc-iphone-dev/llvm/autoconf/config.guess Call Stack (most recent call first): cmake/config-ix.cmake:333 (get_host_triple) CMakeLists.txt:336 (include)
Re: IOS support status
On Friday, 15 June 2018 at 05:35:02 UTC, makedgreatagain wrote: On Friday, 15 June 2018 at 05:26:57 UTC, makedgreatagain wrote: [...] I use git apply --reject --whitespace=fix to patch and it working now. [...] Not sure about llvm, but rather than use his script, it should work with CMake? We normally use CMake and I've never had an issue with it: https://wiki.dlang.org/Building_LDC_from_source#Building_LLVM_manually
Re: Why are we not using libbacktrace for backtrace?
Am Thu, 14 Jun 2018 20:57:05 + schrieb Yuxuan Shui: > On Thursday, 14 June 2018 at 17:26:50 UTC, Johannes Pfau wrote: >> Am Thu, 14 Jun 2018 01:19:30 + schrieb Yuxuan Shui: >> >>> Just ran into a problem where program will crash during stack trace. >>> Turns out not only does druntime not support compressed debug info, it >>> cannot handle it at all. >>> >>> So I was thinking why don't we use a existing and proven library for >>> this, instead of roll our own? >> >> GDC uses libbacktrace since 2013: https://github.com/D-Programming-GDC/ >> GDC/blob/master/libphobos/libdruntime/gcc/backtrace.d >> >> I think the main problem for DMD/LDC is that libbacktrace is not an >> installed library, it's only available while building GCC. > > libbacktrace is a standalone library: > https://github.com/ianlancetaylor/libbacktrace > > GCC is using it. It was initially developed for GCC and only available in the GCC tree. Ian Lance Taylor is a GCC developer. However, my point is that libbacktrace does not install as a .so shared library. Try to find packages for debian, rhel, ... It's just not distributed. As there is a standalone github repo now, the DMD builds could probably compile the source code into libdruntime like GCC does, but it's not as simple as linking a library. -- Johannes
