The POPCNT instruction should not require sizes on memory operands.
Add the appropriate size flags for that to work.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Remove duplicate entry for the "error" warning class; leave at the end
with "all", as being another meta-warning class.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Retroactively document the following changes to the warning options:
- gcc-like syntax (-Wfoo, -Wno-foo)
- "all" alias
- "error" metawarning
Added in 2.00rc1 but never documented.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Better grammar and fix incorrect description of the number-overflow
warning (it is not just limited to 64-bit arithmetic overflow, it also
triggers when trying to squeeze in a value which is too large into an
immediate.)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The code to parse the -w/-W options was updating warning_on[], not
warning_on_global[], but warning_on[] is reset at the beginning of
each pass (to let the warning directive work); as a result the -w/-W
options don't actually do anything at all.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
When issuing warnings for EA displacements during address generation,
actually look a the proper operand!
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The CRC32 instructions require F2, but can also take a 66 prefix to
set the operand size. This is not the SSE model of prefix extension.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Not all backends can handle being handled an intrasegment OUT_REL*ADR,
and we don't fix them up in common code either (which would be the
logical thing to do -- right now we fix them up in a bunch of
individual places.)
For now, just fix up the one in address generation.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The "bin" format was misinterpreting the overloading of the "size"
argument to out(), which caused another source of 64-bit relative
offset errors.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
It is unclear if we will ever see any "naked" (absolute bytes)
OUT_REL*ADR coming from the assembler, but if we do, we should
generate them correctly.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Now when the assembler is properly generating the address that we push
down to the backend, enable requesting an exact value for these
relocations (these are pointing to a specific GOT or PLT slot; the
addend is used to adjust the computed value in the instruction, not
for offset for the symbol.)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The "size" argument to the OUT_REL*ADR output types is actually
intra-instruction offset, not the actual size. Thus, emit the size
properly.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
For OUT_REL*ADR, the "size" argument is actually the offset inside the
instruction; that is in fact why we encode the real size in the
instruction itself. Thus, emit the offsets properly using this
mechanism when generating relative EAs.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Show an artificial case where we bind to the wrong symbol, due to the
confusion in the output system between the size of relative symbols
and their position.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Fix the arithmetic for relative GOT/PLT references.
We still can't enable exactitude, because of the assumption that
"size" is always the proper adjustment for the offset of the
displacement inside the instruction, which is wrong in the case of
displacements that are followed by an immediate. This also affects
the list file, so it really should be fixed.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
GOTOFF64 is used for local variables (as a 64-bit offset from the GOT;
only needed in the Medium PIC or Large PIC models.) It therefore
should *not* be a elf_add_gsym_reloc() invocation.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
I am having a bit of a hard time understanding the proper operation of
the "exact" flag to elf_add_gsym_reloc(). We apparently won't
generate proper GOTOFF64 relocations with this flag set; it is
possible that there are *no* proper uses of this flag. This clearly
needs to be figured out.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
GOT and PLT references need a symbol; after all, they reference a GOT
or PLT slot. Thus, they need elf_add_gsym_reloc(). Mungify the
interface so that they can communicate the need for the PC-shifted
offset into the relocation.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
When generating an address that is *not* tied to a symbol, we just
want to emit the bytes. I believe the assembler is already supposed
to do that for us, but just in case, do it right here too.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The x86-64 ABI wants the symbol addend to reside in the addend field
of the RELA relocation, not in the code stream. Apparently it's
something one can get away with, but the linker would still botch it
for some cases. Change it so we pass the proper output and emit zero
into the code stream.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
A typo in checkin c1377e9a98dd5ca6f7900c048df5d346d1733d05 caused a
bunch of signed-byte immediates to incorrectly be issued as zero.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Try to make the various GOT relocations do the right thing in ELF64,
including erring out when appropriate.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
When discussing the standard macro packages in the context of
__USE_*__ macros, link to them as well as to the %use directive.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
