bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/19381] Warn on instructions accessing small memory addresses, t


From: josh at joshtriplett dot org
Subject: [Bug gas/19381] Warn on instructions accessing small memory addresses, to catch un-tagged immediates
Date: Tue, 22 Dec 2015 22:21:54 +0000

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]