possible insmod bug

[Norm Dresner <ndrez@att.net>]

I’m having a problem because INSMOD is not loading one module correctly.
Here’s the system:
	RH 5.2 w/Real-Time Linux 0.9J extensions to the kernel
	gcc-2.7.2.3-14
	binutils (ld) 2.9.1.0.15-1
	modutils  (insmod) 2.1.85-9

An interface board I’m using has its 64K dual-ported segment located in
PC-address space at 0x000D0000, so I’m trying to get the module compiled so
that a particular `segment’ falls at that address so I can use direct
addressing of registers instead of having to dereference pointers for every
access.

Here’s how the memory is declared in the C-function that uses it:

	unsigned char	  DualPortedMemory[2]  
		__attribute__ ((section (".DPM" ) ) )   
			={0x68,0x89};

and here’s the loader command-file (invoked with -T load_cmds) on the
ld-line of the make-file:


MEMORY	{
		 DUALPORT (rw)  :  ORIGIN = 0x000D0000   , LENGTH = 64K 
		}			 


SECTIONS	{
		.bss				:	{ *(.bss) }
		.text				:	{ *(.text) }
		.data				:	{ *(.data) }
		.note				:	{ *(.note) }
		.comment			:	{ *(.comment) }
		.rodata				:	{ *(.rodata)  }  
		.DPM 0x000D0000 (NOLOAD) :	{ *(.DPM) }   >DUALPORT :NONE
		}

The headers of the linked-moduel (as examined with objdump) show that the
segment .DPM is located at the right address:

dummy.o:     file format elf32-i386

Sections:
Idx Name          Size          VMA          LMA           File off      Algn
			.	.	.
  6 .DPM          00000002  000d0000  000d0000  00001218  2**0
                  ALLOC

and the load-map from the insmod command has the following:

	Sections:     	Size           Address   Align
	.moduse     	00000004  0807a000  2**2
	.text           	0000088e  0807a004  2**2
	.rodata         	00000358  0807a892  2**0
	.data           	0000050c  0807abec  2**2
	.bss            	0000009c  0807b0f8   2**2
	.DPM            	00000002  0807b194  2**0

showing that, despite everything I’ve tried, insmod insists on loading the
module without properly relocating the .DPM-segment to 0x000D0000.

I’ve tried just about every possible combination of things in the loader
command-file, but that doesn't seem to be the problem since the disassemby
of the loader’s output shows that references to array DualPortedMemory[]
are being correctly relocated to the .DPM segment located at the correct
address.

I’ve scanned the code for an older version of insmod (which is all I could
find quickly) and it looks like it was never designed to do what I want it
do .

1. Is there something obvious I’m missing?
2. Has anyone every done this successfully before?
3. Can anyone confirm this "bug"?

I’d like to exhaust all possible approaches before I start creating dozens
of pointers – an error-prone approach if the underlying structures change
radically.

Thanks.

	Norm