BUG #6331: Cross compile error/aborts. Works if '--disable-spinlock' is used

On 12/12/2011 5:09 PM, vbberdin@yahoo.com wrote:

The following bug has been logged on the website:

Bug reference: 6331
Logged by: Victor Berdin
Email address: vbberdin@yahoo.com
PostgreSQL version: 8.4.9
Operating system: Linux (Ubuntu/Linaro 4.5.2-8ubuntu4)
Description:

arm-linux-gnueabi-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv
-I../../../../src/include -D_GNU_SOURCE -c -o xlog.o xlog.c
/tmp/cclQLJ69.s: Assembler messages:
/tmp/cclQLJ69.s:645: Error: selected processor does not support Thumb mode
`swpb r3,r3,[r0]'
/tmp/cclQLJ69.s:6821: Error: selected processor does not support Thumb mode
`swpb r2,r2,[r0]'

Are you sure you're using the correct assembler?

Try tweaking your PATH so that symlinked names for the ARM toolchain are
all on your PATH before your host toolchain.

If that's not the issue then its presumably an issue with Pg's configure
script/Makefiles invoking the wrong tool in a cross-compile situation,
because AFAIK there's no ARM asm code or ARM gcc intrinsics hidden away
in Pg, and that'd be the only other way to get those kinds of errors.

--
Craig Ringer

Craig Ringer <ringerc@ringerc.id.au> writes:

On 12/12/2011 5:09 PM, vbberdin@yahoo.com wrote:

arm-linux-gnueabi-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv
-I../../../../src/include -D_GNU_SOURCE -c -o xlog.o xlog.c
/tmp/cclQLJ69.s: Assembler messages:
/tmp/cclQLJ69.s:645: Error: selected processor does not support Thumb mode
`swpb r3,r3,[r0]'
/tmp/cclQLJ69.s:6821: Error: selected processor does not support Thumb mode
`swpb r2,r2,[r0]'

Are you sure you're using the correct assembler?

Try tweaking your PATH so that symlinked names for the ARM toolchain are
all on your PATH before your host toolchain.

If that's not the issue then its presumably an issue with Pg's configure
script/Makefiles invoking the wrong tool in a cross-compile situation,
because AFAIK there's no ARM asm code or ARM gcc intrinsics hidden away
in Pg, and that'd be the only other way to get those kinds of errors.

No, you're mistaken about that: we do have inline assembly code in
s_lock.h, and this message does look to be complaining about that code,
because "swpb %0, %0, [%2]" is exactly what the TAS() macro generates
for ARM.

However, unless the OP is prepared to offer some other inline TAS
implementation that is portable to more flavors of ARM than this one is,
we're unlikely to change it. --disable-spinlocks is exactly what you're
supposed to do if you don't have a supported processor, and his machine
evidently isn't, even if it calls itself an ARM.

It's also possible that his target processor actually can do swpb, but
he needs to use some other gcc flags to persuade gcc of that.

regards, tom lane

On 13/12/11 08:43, Tom Lane wrote:

Craig Ringer <ringerc@ringerc.id.au> writes:

because AFAIK there's no ARM asm code or ARM gcc intrinsics hidden away
in Pg, and that'd be the only other way to get those kinds of errors.

No, you're mistaken about that: we do have inline assembly code in
s_lock.h, and this message does look to be complaining about that code,
because "swpb %0, %0, [%2]" is exactly what the TAS() macro generates
for ARM.

Ah - my mistake, and thanks for the correction. I really should've seen
that.

--
Craig Ringer