What version of gcc toolchain build this demo tested against ?
I tried LPCXpresso v3.6.3 [Build 317] [08/04/2011] (should be very similar to RedSuite as stated in demo name).

E:\lpcxpresso_3.6.3_317\Tools\bin>arm-none-eabi-gcc.exe --version
arm-none-eabi-gcc.exe (Code Red/Red Suite/2009_01_C) 4.3.3
...

Here is the fragment from RTOSDemo_RDB1768.map:

privileged_functions
0x000017980x5d4 ./src/FreeRTOS/portable/GCC/ARM_CM3_MPU/port.o
0x000018d8xPortStartScheduler
0x00001990xPortSysTickHandler
0x0000193cxPortPendSVHandler
0x00001930vPortEndScheduler
0x00001810vPortSVCHandler
0x00001798pxPortInitialiseStack
0x00001b8cvPortStoreTaskMPUSettings

.text0x00001d6c0x51d6
0x00004000. = (__privileged_functions_start__ + _Privileged_Functions_Region_Size)
 *fill*0x00001d6c0x400000
 *(.text*)
 .text.Reset_Handler
0x00005d6c0x84 ./src/cr_startup_lpc17.o
0x00005d6cReset_Handler
0x00005d6cResetISR

Look at .text section start address. It's not 0x00004000, but shifted by 0x00004000 from end of privileged_functions section end.
Location counter assignments in linker script such as

/* Non privileged code kept out of the first 16K or flash. */
. = __privileged_functions_start__ + _Privileged_Functions_Region_Size;

doesn't work as expected.
The same results with Yagarto GNU toolchain (arm-none-eabi-gcc.exe (GCC) 4.6.0).
Although some tutorials doesn't recommend location counter assignments, GNU ld manual clearly describes this behavior and provides an example usage even.

Hmm. I read again ld manual and found that it's correct behavior because location counter inside section block is relative. That line must be removed and line

/* Non privileged code kept out of the first 16K or flash. */
. = __privileged_functions_end__;

must be placed at end of privileged_functions block.
And it works as expected both in lpcexpresso and yagarto.

I hurried again :) Final correct line:

/* Non privileged code kept out of the first 16K or flash. */
. = _Privileged_Functions_Region_Size;

Please, do fixes I mentioned. Although demo works fine (only because the LPC1768 flash luckily resides on 0x0, but this demo ported to STM32F2 with flash at 0x8000000 fails), these fixes must be done to get it linked correctly.

Posted a bug report