Fix rt.backtrace.dwarf

[kinke]

Cherry-pick of dlang#2151 (still pending).

I don't know if the fixed bug has the potential of being the cause for the EH issue on ARM and other EH strangeness, but it could have caused a segfault due to reading 250 bytes past the ??:? \0 string constant, if I studied the code correctly.

[kinke]

Yep, when using a 64K buffer, the executable segfaults reproducibly for run.dlang.io: https://run.dlang.io/is/iKTnTh

That must be an invalid optimization on our part, as with -O alone, there's this call (which would throw an exception - while generating a previous exception's stack trace...):

call void @_d_array_slice_copy(i8* nocapture nonnull %buffer1.sub, i64 65536, i8* nocapture getelementptr inbounds ([7 x i8], [7 x i8]* @.str, i64 0, i64 0), i64 6

with clearly diverging sizes (65536 vs. 6), so adding -release shouldn't replace the call by a 64KB-memcpy.

Edit: Well, DMD shows the same issue - exception with -O alone, segfault with -release (with and without -O) (using a 128K buffer) - it's just the disabled bounds checks. Given that the lengths would be statically known, that's a bit surprising/disappointing, but oh well.

[kinke]

I tested Joakim's reduced testcase with this in the ARM emulator, still fails.

[kinke]

I just hit this again on Ubuntu 18.04.