On Thu, 18 Jul 2002, George Agasandian wrote:
> My fault is that I forgot to write I am developing embedded software.
> However the problem is much more general. If you know how compilers
> work, you can usually guess how to solve some problems.
actually, i think you are either not compiling the module properly, or are
using a bad system configuration. calling the function by name should be
ok (in other words - result a far call), if you compile the module the
same wey modules are compiled inside the kernel's tree.
the question would be, then - give us more info:
1. linux kernel version.
2. gcc version used to compile the kernel module.
3. gcc version used when compiling the kernel itself (they should be the
same, or you're in for a mess).
4. what kind of linux install are you using - a cut-down distribution (if
so - which and what version? if not - how did you build it?
5. what version of modutils you are using - for each kernel, there's a
given version of modutils (or higher) that should be used.
in general, the way you have written and compiled your module is something
i have _never_ seen before. you might want, as an exersize, to check the
exact gcc command used to compile an existing kernel module, inside your
kernel's tree, and then try compiling your own module using the same
command line.
> Well, function is called by some jump instruction. Basically, jump
> instruction can be either direct or indirect. Direct instruction in many
> cases is limited by address you can specify there (usually inside one or
> a few number of pages), but indirect one (which is using a register) is
> much moreflexible. Compiler uses the first way if you just put a
> function name in your code. The second way is used when you call a
> function by its pointer;
> e.g.:
> typedef void (*func)(char *, ...);
> func p_printk = &printk;
> ..
> (*p_printk)("Hello World\n");
naturally, this has to work, because a pointer has to be a 32-bit object,
forcing the use of a far call. however, as i understand it (looking
at 'objdump --disassemble some_module.o'), when you compile the module
_properly_, calls to undefined symbols go via a jump-table, whose contents
is initialized by 'insmod', when loading the module. you can try to read
the source of 'insmod' to verify (or refute) that.
> Another note: Sometimes, code portions can be located at the same
> physical space, but accessible via different addresses: cache, virtual,
> etc... This, actually, is my case. So, direct jump does not work for me.
as far as i understand, code running insde the kernel still goes via
virtual memory - when you want to access physical memory, you need to use
functions that map virtual addresses into physical addresses.
as for the cache - it shouldn't affect the code you write. if a cache
breaks a near call (or near jump) - i'd imagine this is a
firmware/hardware bug.
--
guy
"For world domination - press 1,
or dial 0, and please hold, for the creator." -- nob o. dy
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
