On Mon, May 07, 2007 at 01:47:02PM -0400, Quentin Godfroy wrote:
> I have made another patch, which I hope should not break anything this
> time. I tested it on an x86_64 kernel with 32 and 64 bits executables,
> PIE and not PIE (well my only PIE are libc-2.5.so and ld-2.5.so). I
> rejoined the loo
On Fri, May 04, 2007 at 10:09:21AM -0400, Quentin Godfroy wrote:
> On a dynamic ELF executable, the current kernel loader gives to the
> interpreter (in the AUXV vector) the AT_PHDR argument as :
> offset_of_phdr_in_file + first address.
>
> It can be wrong for an executable where the program head
On Fri, May 04, 2007 at 09:24:05PM -0700, Jeremy Fitzhardinge wrote:
> > Indeed, I haven't seen that. For ET_DYN executables, it could be done a
> > thing like load_addr+elf_ppnt->p_vaddr (in the function that creates the
> > auxv, as ity has access to the elf header), and for ET_EXEC do what I
> >
On Fri, 4 May 2007 23:34:08 -0400 Quentin Godfroy <[EMAIL PROTECTED]> wrote:
> By the way, is init 32 bits or 64 bits? It could break the ia32
> emulation thing, but not the 64bit native mode.
akpm2:/home/akpm> file /sbin/init
/sbin/init: ELF 64-bit LSB executable, AMD x86-64, version 1 (SY
Quentin Godfroy wrote:
>> Won't this break with ET_DYN executables? And besides, isn't this the
>> same thing?
>>
>
> Indeed, I haven't seen that. For ET_DYN executables, it could be done a
> thing like load_addr+elf_ppnt->p_vaddr (in
On Fri, May 04, 2007 at 04:22:08PM -0700, Andrew Morton wrote:
> This patch kills my FC6 machine (using a config which was derived from RH's
> original):
>
> Freeing unused kernel memory: 368k freed
> Write protecting the kernel read-only data: 959k
> request_module: runaway loop modprobe binfmt-4
On Fri, May 04, 2007 at 04:31:49PM -0700, Jeremy Fitzhardinge wrote:
> Quentin Godfroy wrote:
> > + elf_ppnt = elf_phdata;
> > + for (i = 0; i< loc->elf_ex.e_phnum; i++, elf_ppnt++)
> > + if (elf_ppnt->p_type == PT_PHDR) {
> > + phdr_addr = elf_ppnt->p_vaddr;
> >
Quentin Godfroy wrote:
> + elf_ppnt = elf_phdata;
> + for (i = 0; i< loc->elf_ex.e_phnum; i++, elf_ppnt++)
> + if (elf_ppnt->p_type == PT_PHDR) {
> + phdr_addr = elf_ppnt->p_vaddr;
>
Won't this break with ET_DYN executables? And besides, isn't this the
s
On Fri, 4 May 2007 10:09:21 -0400
Quentin Godfroy <[EMAIL PROTECTED]> wrote:
> On a dynamic ELF executable, the current kernel loader gives to the
> interpreter (in the AUXV vector) the AT_PHDR argument as :
> offset_of_phdr_in_file + first address.
>
> It can be wrong for an executable where the
9 matches
Mail list logo
