/proc/ksyms change for IA64

The IA64 use of descriptors for function pointers has bitten ksymoops. For those not familiar with IA64, &func points to a descriptor containing { &code, &data_context }. System.map contains the address of the code, /proc/ksyms contains the address of the descriptor. insmod needs the descriptor address, ksymoops and debuggers need the code address, /proc/ksyms needs to contain both addresses, with one of them prefixed by a special character.

EXPORT_SYMBOL() cannot distinguish between &function and &data. Telling everybody that they must type EXPORT_SYMBOL_FUNCTION or EXPORT_SYMBOL_DATA is not an option, the second symbol has to be automatically added after linking vmlinux and modules. I want to fix this problem in user space, with no changes to to kernel code. My proposal for kernel 2.5 is :-

* In System.map and /proc/ksyms, label foo addresses the code, not the descriptor. Label &foo addresses the function descriptor.

* foo has symbol versions, &foo does not.

* In kernel build, all objects that export symbols are post processed immediately after they are compiled. On most architectures the post process is a no-op. On IA64 it runs a program from modutils that identifies exported function pointers and modifies the ksymtab and kstrtab, see below.

* At run time, insmod does its normal address fixup processing first, including checking for symbol versions. If the existing code succeeds without unresolved symbols, insmod modifies the address fixup so a reference to foo is resolved to &foo, iff both foo and &foo are in /proc/ksyms.

This has the benefit that all the changes are in modutils plus a small change to the kernel build, no other user space tools are affected. Most user space programs expect foo to address the code, not the descriptor, AFAIK it is only insmod that needs the descriptor. This change will also affect any code that tries to front end functions from modules but IMNSHO code should not be doing that. If this breaks binary only modules - tough.

One problem that always has to be addressed with modutils is version skew between user space and the kernel. With this approach, if you build a new kernel with old modutils then the post processing program will not be available so ksyms has the old format and the old insmod behaviour applies, ksymoops will get errors but the kernel will still run. With a new modutils but an old kernel you get the old behaviour. The only way you can get problems with version skew is to compile a kernel on one machine with new modutils and install on another machine with old modutils, modules will oops. I don't see this as a problem, the IA64 population is fairly small, in any case gcc cross compile for IA64 has problems right now.

The new modutils supplied program (/usr/bin/modules_post) will look through the __ksymtab section for an object. For each exported symbol, look at the data it references. If that data contains two relocatable addresses, one pointing to a text symbol, the other to a data symbol and the text symbol has the same name as the exported symbol then this is a descriptor. Change the exported symbol name to &foo and add an exported symbol foo that points to the code.

Note: This is modutils 2.5 stuff. modules_post needs to use BFD which
current modutils does not use, this adds a new requirement when compiling modutils. Using BFD is the only way I can handle all the relocation types, especially in cross compile mode. It may or may not get backported to modutils 2.4, probably not. ksymoops on IA64 2.4 will just have to live with lots of warnings.

In message <[email protected]> you write:

Eewwww....

How about just adding /proc/ksyms-ia64 with the code pointers
which contains the ia64 code addresses required by ksymoops and debuggers. These are, after all, less vital than insmod.

Cheers,
Rusty.
--
Premature optmztion is rt of all evl. --DK

That requires changes to every kernel debugger, oops decoder etc. I don't control all of Linux debugging yet ;). It is also more work because it requires kernel changes as well as lots of user space.

BTW, do you know that you are sending from 144.137.82.79 which has no reverse DNS? Oh wait, it's Telstra :(

Welcome to Telstra country, on any day you can hear the customers being ripped off.

In message <[email protected]> you write:

For ia64 only. IMHO, that's a better line to draw.

Rusty.
--
Premature optmztion is rt of all evl. --DK

My approach preserves the notion that a ksyms entry points to the data or code, changing the function descriptor to a different name in ksyms. Your approach breaks that notion and introduces a special case for ia64 ksyms. My approach only needs changes to modutils. Your approach requires changes to the kernel and to every utility that understands ksyms. Guess which approach I am doing?

[email protected] (Keith Owens) wrote on 02.08.01 in <[email protected]>:

That sounds suspiciously like what I remember from PPC. How is this solved on the PPC side?

MfG Kai

Best guess, without access to a PPC box, is that it is not solved. Any arch where function pointers go via a descriptor will have this problem.

PPC users, does /proc/ksyms contain the address of the function code or the address of a descriptor which points to the code? It is easy to tell, if function entries in /proc/ksyms are close together (8-128 bytes apart) and do not match the addresses in System.map then PPC has the same problem as IA64. If this is true, what is the layout of a PPC function descriptor so I can handle that case as well?

It's an address of a function. Verified by matching with the system map. I'm not sure where to look for what you need, however. I've checked the ppc arch specific code, but it's not apparent to me what I'm looking for (sorry, I'm still learning about the kernel's structure). If you can suggest what/where to look I'll dig it up for you.

Peter A. Castro <[email protected]> or <[email protected]>
	"Cats are just autistic Dogs" -- Dr. Tony Attwood

This is what the MacOS does on ppc, but it's specific to the MacOS, and is part of the way the MacOS seamlessly integrates 68k code and ppc code so that they didn't have to have both 68k and ppc versions of all the system calls. This was basically a trick to pack in extra information along with a function pointer to tell the Mixed Mode Manager if it needed to run the 68k emulator and also how to setup the right context. I'm pretty sure that Linux just does the normal address for function pointers just like most other architectures.

Brad Boyer
[email protected]

The idea of a 'transition vector' to refer to a piece of code (and the
proper data-globals area to go with it) came part and parcel from the IBM AIX runtime model, and had nothing to do with a MixedMode routine descriptor as you describe above. The two are separate beasts.

A MixedMode descriptor helps classic MacOS handle all of the arguments,
stack layout, and return value issues when hopping from one processor architecture to another at runtime. Transition vectors are used far more often, for any old inter-library call (for example, every app call to the OS, even when both caller and callee are PPC native).

--
Rob Barris Quicksilver Software Inc. [email protected]

This isnt the case on ppc32, but is at the moment on ppc64.

Anton

What the hell? You've got everything you need right there in the obj subdirectory. Please don't bring libbfd back to life in modutils.

r~

Cross compile mode. Nothing in modutils works unless it is running on the machine it was compiled for. As more modutil functions get pushed back into kbuild time, this is getting to be a problem. I could do all my own code for endianess and size differences between host and target, but why bother when bfd already does it for me?

How about bfd is a bloated monstrosity. Right now libobj is just over 10k; you'll be looking at a _minimum_ of 150k to pull in only the linking code from libbfd.a.

How about bfd is an unmaintainable nightmare? If you've not spent the last couple of years working on bfd, save your sanity and don't start.

It would take only a day or three to fix up libobj to cross compile. If you don't want to do it, let someone else.

r~