Turns out the checks could fail spuriously if the starting alignment is non-zero,
e.g. `align 8,$C0` in HRAM. (Fixes #2113.)
This was tripped up by a test added to exercise the linker's section placement algorithm
on a similar aligment-related issue. :D
Note that this may be caused by the code in question pre-dating alignment offsets,
and we never checked. That said, these checks only work due to the regions' starting
addresses being no more aligned than their size (..if that makes sense?), so allowing
custom memory regions (#524) could violate that assumption and make those checks incorrect.
This reverts a change introduced in fd78a9ae8, though it wasn't that commit's main point
so I'm feeling okay with undoing that.
This feels like an overkill change, using a static string is good enough for this
since we never modify this. I have considered using `string_view` instead, to have
the best of both worlds, but that's not NUL-terminated so our print functions
get a little grumpy.
RGBASM does this itself, so should not output sections with 16-bit
alignment, but an invalid object file could otherwise cause
`getPlacement` to infinitely loop.
* Use clang-tidy `misc-include-cleaner` for IWYU `#include` cleanup
* Use `std::optional<size_t>` instead of `ssize_t`
* Rename some functions in linkdefs.hpp
* Fix header order
- "Double quotes" for strings (filenames, section names, CLI option arguments, etc)
- 'Single quotes' for characters and CLI option flags
- `Backticks` for keywords and identifiers (symbol names, charmap names, etc)
CLI option flags also have their leading dashes
* Remove `err` and `warn`, keep `errx` and `warnx`, using them in RGBGFX too
* Separate RGBGFX and RGBLINK warnings/errors from main options
* Separate `report` function into `error` and `fatal` messages
* Implicit newlines for most RGBASM errors
These fall into a few categories:
- `_unreachable()`
- Verbose print messages
- Errors that should never practically occur (alloc/read/write failure,
more than UINT32_MAX anonymous labels, etc)
This allows us to control the order in which sections are iterated,
instead of it depending on the internals of `std::map`. (This order
is arbitrary, but should be deterministic regardless.)
- Since we have style rules to include foo.hpp at the top of its
corresponding foo.cpp, this takes any headers included by foo.hpp
as being also guaranteed for foo.cpp.
- Use C-style <foo.h> instead of <cfoo>, since the latter only
guarantees putting symbols in the `std` namespace, which we are
not using for C functions (e.g. `printf` not `std::printf`).
- Remove now-unused `__PRETTY_FUNCTION__` reporting
Rangi
ISSOtm
Rangi
Rangi42