ld -R behaviour

[Kristis Makris]

Hello,

I am trying to link an object file using the absolute memory addresses
found in another object file. The exact syntax I am using is:

$ ld -R ../../../../kernel/kernel-source-2.4.20.mod/vmlinux -r
dynreplace_scheduler_v3.o -o dynreplace_file.o

However some symbols found in dynreplace_scheduler_v3.o do not use the
absolute memory addressses found in vmlinux after linking. They just
remain undefined. Here are all the symbols in dynreplace_scheduler_v3.o


$ nm dynreplace_scheduler_v3.o
         U __mmdrop
00000040 ? __module_description
00000000 ? __module_kernel_version
0000001d ? __module_license
         U __switch_to
         U aligned_data
00000000 d call_count.951
         U default_ldt
00000000 t gcc2_compiled.
         U init_task_union
         U irq_stat
         U jiffies
         U kstat
         U nr_running
         U printk
         U runqueue_head
00000000 T schedule_v3
00000320 T schedule_v3_endlabel
         U set_ldt_desc

And here are a couple of symbols that are present in vmlinux but are
left undefined in the dynreplace_file.o:

$ nm ../../../../kernel/kernel-source-2.4.20.mod/vmlinux |grep -i
runqueue_head
c0208f88 d runqueue_head

]$ nm ../../../../kernel/kernel-source-2.4.20.mod/vmlinux |grep -i
aligned_data
c0263520 d aligned_data

$ nm dynreplace_file.o |grep -i runqueue_head
         U runqueue_head

$ nm dynreplace_file.o |grep -i aligned_data 
         U aligned_data


Why would that happen ? All other undefined symbols in
dynreplace_scheduler_v3.o had the correct absolute memory addresses
referenced in the outputed dynreplace_file.o.