Supports writing the first function. Still TODO is:
* handling the .debug_line header growing too large
* adding a new file to an existing compilation
* adding an additional function to an existing file
* handling incremental updates
* adding the main IR debug ops for IR instructions
There are also issues to work out:
* readelf --debug-dump=rawline is saying there is no .debug_str section
even though there is
* readelf --debug-dump=decodedline is saying the file index 0 is bad
and reporting some other kind of corruption.
* the .debug_line header is written properly
* link.File.Elf gains:
- SrcFn, which is now a field in Module.Fn
- SrcFile, which is now a field in Module.Scope.File
* link.File.Elf gets a whole *Package field rather than only
root_src_dir_path.
* the fields first_dbg_line_file and last_dbg_line_file tell where the
Line Number Program begins and ends, which alows moving files when
the header gets too big, and allows appending files to the end.
* codegen is passed a buffer for emitting .debug_line
Line Number Program opcodes for functions.
See #5963
There is some work-in-progress code here, but I need to go make some
experimental changes to changing how to represent source locations and I
want to do that in a separate commit.
This shaves off one syscall (we use one instead of two if we were to
use `windows.OpenFile` wrapper). Clean up flag generation in `OpenFile`.
Hopefully, we're in a much better place to *almost* support `openW`
and `openatW`.
This way, we can remove more `kernel32` calls such as `RemoveDirectoryW`
or `DeleteFileW`, and use `std.os.windows.DeleteFile` instead which
is purely NT-based.
Replace them with `std.os.windows.OpenFile` instead. To allow
creation/opening of directories, `std.os.windows.OpenFileOptions`
now features a `.expect_dir: bool` member which is meant to emualate
POSIX's `O_DIRECTORY` flag.
As discussed in the previous commit, it would be better to avoid
function pointers to syscalls and explicitly split the control
path into two function calls instead. This commit addresses that
for `std.os.windows.DeviceIoControl`.
When there are no format parameters, it simply calls `writeAll`. This
has the effect of no longer emitting a compile error for using `{}` and
not having any parameters, however, at this point in the development
process of Zig I think that tradeoff is worthwhile.
On the other hand, it might be OK to simply define formatting to work
this way. It's a common pattern to use the formatting function's format
string `"like this", .{}` instead of `"{}", .{"like this"}`, which can
lead to accidentally putting control characters in the formatting
string, however, with this change that works just fine.
This commit adds a Zig wrapper for `kernel32.DeviceIoControl` which
applies ReactOS logic for deciding whether to use
`ntdll.NtDeviceIoControlFile` or `ntdll.NtFsControlFile` based on the
value of passed `IO_CONTROL_CODE`. The decision logic is based on the
logic found in ReactOS found in the following [link].
Thanks to Daurnimator for finding this bit in ReactOS!
[link]: https://doxygen.reactos.org/d3/d74/deviceio_8c.html
