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/
This archive was generated by hypermail 2b29 : Sat Aug 05 2000 - 20:16:02 EDT