Re: [PATCH] cross-architecture ELF clean up

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

On Thu, 28 Jun 2007, Jeremy Fitzhardinge wrote:

> Roman Zippel wrote:
> > This could be avoided by reordering things within elf.h, but is it really
> > necessary since there is no user of this right now?
> >   
> 
> Well, yes, I don't have much need to include ELF headers in asm now, but I
> still think its worth separating the arch-specific definitions from asm/elf.h
> and all the other stuff they pull in.  Specifically, the structure forward
> declarations and constants have very few external dependencies, but the
> structure definitions - particularly the arch-specific ones - have very wide
> dependencies, which is what I'm trying to solve.  Very few pieces of code care
> about the arch-specific structures.

The problem I have is that you want to separate _all_ constants, which 
doesn't really make sense to me, because many of them are useless without 
the correspending structures.

> > module.h does indeed pull in way too much, but instead of hacking headers
> > into little pieces, IMO it would be better to solve the real problem.
> >   
> 
> No, that's not the real problem; its a side-effect of the real problem.  The
> real problem is that linux/elf.h ends up bringing in too much.

Please define the problem more specific. :)

>  arch/powerpc,
> for example, has its own stripped down copy of elf.h for bootloader stuff in
> order to avoid this extra crud.  The fix is to make it possible to get just
> the appropriate ELF definitions without getting everything else.

The bootloader is no kernel code and thus the elf header pull in a lot 
less:

$ gcc -c foo.c -Iusr/include --trace-includes
. usr/include/linux/elf.h
.. usr/include/linux/types.h
... usr/include/linux/posix_types.h
.... usr/include/linux/stddef.h
.... usr/include/asm/posix_types.h
... usr/include/asm/types.h
.. usr/include/linux/auxvec.h
... usr/include/asm/auxvec.h
.. usr/include/linux/elf-em.h
.. usr/include/asm/elf.h
... usr/include/asm/ptrace.h
.... usr/include/asm/ptrace-abi.h
... usr/include/asm/user.h
.... usr/include/asm/page.h

One could remove ptrace.h but otherwise the result looks quite reasonable.

> There's the secondary problem that lots of ELF stuff is copy'n'paste
> duplicated across all the architectures, but all they really care about is one
> of two sets of parallel definitions (32 or 64 ELF structures).  That was the
> secondary

Some of it you could put into linux/elf, e.g.:

#if ELF_CLASS == ELFCLASS32

typedef Elf32_Ehdr     Elf_Ehdr;
typedef Elf32_Phdr     Elf_Phdr;
typedef Elf32_Shdr     Elf_Shdr;
typedef Elf32_Sym      Elf_Sym;
typedef Elf32_Dyn      Elf_Dyn;
typedef Elf32_Rel      Elf_Rel;
typedef Elf32_Rela     Elf_Rela;

typedef Elf32_Addr     Elf_Addr;

#elif ELF_CLASS == ELFCLASS64

typedef Elf64_Ehdr     Elf_Ehdr;
typedef Elf64_Phdr     Elf_Phdr;
typedef Elf64_Shdr     Elf_Shdr;
typedef Elf64_Sym      Elf_Sym;
typedef Elf64_Dyn      Elf_Dyn;
typedef Elf64_Rel      Elf_Rel;
typedef Elf64_Rela     Elf_Rela;

typedef Elf64_Addr     Elf_Addr;

#else
#error
#endif

> > I played with it a little and the patch below moves a lot stuff out of
> > module.h, so this would drastically reduce the header dependencies.
> > Unless there are major objections, I can test the patch a little more and
> > convert the other archs.
> >   
> 
> Well, it seems like a large fiddly patch which only solves part of the problem
> I want to solve; actually it doesn't help me at all, but it achieves one of
> the side-effects of my patch. The arch changes make it look pretty awkward to
> merge.

The patch does help you quite a bit, you don't have to cleanup elf.h so 
it's usable by the whole kernel. Only few parts now really need it and 
depend on it, which makes the extensive splitup unnecessary only to 
reduce header dependencies.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/