Assertion failed: ((isInt<32>(Value) || isUInt<32>(Value)) && "Value does not fit in a 4Byte Reloc"

[Quuxplusone]

Bugzilla Link	PR10583
Status	RESOLVED FIXED
Importance	P normal
Reported by	Pawel Worach (pawel.worach@gmail.com)
Reported on	2011-08-04 02:06:53 -0700
Last modified on	2011-08-04 19:55:47 -0700
Version	trunk
Hardware	PC FreeBSD
CC	dimitry@andric.com, efriedma@quicinc.com, jasonwkim@google.com, joerg@NetBSD.org, llvm-bugs@lists.llvm.org, rafael@espindo.la
Fixed by commit(s)
Attachments	locore.s (13358 bytes, application/octet-stream)
Blocks
Blocked by
See also

Created attachment 7014
pre-processed locore.s

llvm/clang r136864. Regression introduced between r136841 and r136860.

Original source from FreeBSD kernel sys/i386/i386/locore.s, pre-processed
version attached.

% clang -cc1as -triple i386-unknown-freebsd8.2 -filetype obj -o locore.o
/tmp/cc-PyWIpA.s
Assertion failed: ((isInt<32>(Value) || isUInt<32>(Value)) && "Value does not
fit in a 4Byte Reloc"), function ApplyFixup, file /data/buildslave/freebsd-
clang-i386/src-llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp, line 109.
Stack dump:
0.  Program arguments: /data/buildslave/freebsd-clang-i386/obj/obj-
llvm.2/Release+Asserts/bin/clang -cc1as -triple i386-unknown-freebsd8.2 -
filetype obj -o locore.o /tmp/cc-PyWIpA.s
1.  Program arguments: -triple i386-unknown-freebsd8.2 -filetype obj -o locore.o
/tmp/cc-PyWIpA.s
Abort (core dumped)

[Quuxplusone]

Attached locore.s (13358 bytes, application/octet-stream): pre-processed locore.s

[Quuxplusone]

reduced testcase:

 .data
 .globl IdlePTD
IdlePTD: .long 0
 .text
 movl ((IdlePTD)-0xc0000000), %eax

[Quuxplusone]

It is bad that we assert instead of producing a nice error, but gas produces
the same output for

 movl ((IdlePTD)-0xc0000000), %eax

and

 movl ((IdlePTD)+0x40000000), %eax

which I would call a bug. Any reason you need to use the -0xc form?

[Quuxplusone]

0xc0000000 is used because that's the kernel base macro. The expection here I guess is explicitly 32bit (or 64bit for ELF64) wraparound.

[Quuxplusone]

Yes, the original non-preprocessed code has:

#define KERNBASE  0xc000000   (this via all kinds of in-between macros)
...
#define R(foo) ((foo)-KERNBASE)
...
    movl    R(IdlePTD), %eax

And obviously, in two's complement 32 bits, subtracting 0xc0000000 is
the same as adding 0x40000000. :)

Even the MS assembler agrees. This:

.model flat
.data
foo dd 0
.code
    mov eax,foo-0c0000000h
    mov eax,foo+040000000h
    mov eax,foo-0ffffffffh
    mov eax,foo+000000001h
end

results in:

  00000000: A1 00 00 00 40     mov         eax,dword ptr ds:[40000000h]
  00000005: A1 00 00 00 40     mov         eax,dword ptr ds:[40000000h]
  0000000A: A1 01 00 00 00     mov         eax,dword ptr ds:[00000001h]
  0000000F: A1 01 00 00 00     mov         eax,dword ptr ds:[00000001h]

[Quuxplusone]

Yikes!

okay, looks like the way forward is to relax the assert a bit.

I couldn't find a Warn() equivalent of an assert() in wide use so assert stays for now.

r136954 probably fixes this.