https://sourceware.org/bugzilla/show_bug.cgi?id=19381
--- Comment #3 from Josh Triplett <josh at joshtriplett dot org> --- (In reply to Nick Clifton from comment #2) > You don't say which target you are using - some do have valid low memory > addresses. The default warning threshold would need to be target-specific. Many targets catch accesses to the lowest page of memory to trap NULL pointer dereferences. If some target didn't have that, then sure, it couldn't have this cross-check. Many common targets do, though. And for those that don't have an obvious default target (e.g. if using an -elf target), the user could pass a warning option to set the threshold. (In this case, x86_64-linux-gnu.) > Anyway it does not matter much as this is not really the job of the > assembler or the linker. A simulator or debugger is the appropriate place > for a test such as this. A hardware simulator was precisely how I ended up catching the problem, after hours of debugging and code inspection. (And in the end, it wasn't the simulator itself that directly found the problem, but rather the fact that it disassembled using an assembler syntax that explicitly tags memory accesses.) The assembler is what offers the easy-to-misuse syntax; I don't think it's unreasonable to have a "that's probably not what you meant" warning (just a warning, not an error). This isn't a warning to attempt to catch NULL pointer dereferences in general; that *would* be a job for valgrind or similar. This is a warning to catch memory references to tiny addresses written directly in the instruction, on the theory that absolute tiny addresses are vanishingly rare, and the user almost certainly meant to include the '$' for an immediate value instead. The assembler already has numerous warnings for dubious assembly; for instance, attempting to assemble "addb $0x120, %al" will produce "Warning: 288 shortened to 32". -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
