Messages in this thread | | | Date | Sun, 6 Aug 2000 01:10:30 +0100 | From | Philipp Rumpf <> | Subject | Re: exporting struct offsets to assembler |
| |
On Sat, Aug 05, 2000 at 09:55:34AM -0400, Brian Gerst wrote: > Philipp Rumpf wrote: > > On Sat, Aug 05, 2000 at 12:27:42PM +1000, Andrew Morton wrote: > > So it introduces bogus symbols into System.map. > > These symbols are getting in there anyways. "nm vmlinux" shows: > > 00000000 a EBX ... > 00020000 a VM_MASK > > most of these are from entry.S. They are grepped out when we create > System.map.
That's an architecture-specific problem - on x86 our offsets are 32 bit anyway so using symbols doesn't hurt (I think it'd still make more sense to use preprocessor macros as most architectures do).
I'd also think using absolute symbols might be a nice thing on architectures where we want to look at the firmware data even after boot - and they should show up in System.map.
> > > This _should_ be arch-independent, but there is one potential > > > > What's the point ? The assembly isn't architecture-independent anyway. > The point is that we let gcc/ld take care of these offsets by itself
We need to look at the assembly after each change to struct task_struct anyway - unless it's a complete reordering, adjusting the struct offsets shouldn't hurt too much.
The thread, pt_regs, and sigcontext structures are architecture-dependent so worst-case you end up having an architecture-independent file and an architecture-dependent one using completely different mechanisms.
I also seriously doubt Andrew's mechanism works on all architectures.
> instead of hacking up an external program (which complicates > cross-compiling) to extract them.
It's there. It works. Adjusting it to a new architeture is a matter of 30 minutes (I've done it). If anything writing a new "solution" complicates the build process.
Of course the current @@@ trick is somewhat ugly; I think generating a temporary object, then doing
$(NM) object | grep ' a ' | sed -e 's/^\(.*\) a \(.*\)$$/#define \2 \1/'
might be a better solution (hacked so it actually works, of course).
Philipp Rumpf
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |