https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #30 from Eric Christopher ---
That might be reasonable. As far as I know ld64 doesn't do that yet, but I know
it's been thought about.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #28 from Eric Christopher ---
Ah, but not every platform is ELF :)
ld64 has the flexibility to do this with Mach-O. As I said, I don't have any
better ideas at the moment, but warning that it is possible to break.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #26 from Eric Christopher ---
Sure. Not the general case for other targets though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #24 from Eric Christopher ---
For the record btw, I don't believe there's a reason why the linker couldn't
split up the data section by knowing the size of the variable so it's worth
being very careful here - there be dragons and thin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #23 from Eric Christopher ---
So, I think Jakub's solution is strictly better here as it allows intermixing
of asan and non-asan code. It'll involve a bit of work in llvm's middle end to
keep track of symbol type to make sure to emit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490
--- Comment #4 from Eric Christopher ---
I disagree for bare metal that including endian is the right way, but agree
that __BYTE_ORDER__ is the right way to do this in general.
Thanks Jakub.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490
--- Comment #2 from Eric Christopher ---
Why does it seem like a bad decision? Endianness can be separate from OS (or
bare metal) so I don't see how outputting the macro as a per-cpu define is a
bad thing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
Eric Christopher changed:
What|Removed |Added
CC||echristo at gmail dot com
