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
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
