[davidm@napali.hpl.hp.com: readelf question]

[davidm@napali.hpl.hp.com: readelf question]

[H. J. Lu]

Roland, do you know anything about this?


H.J.
----- Forwarded message from David Mosberger <davidm@napali.hpl.hp.com> -----

Delivered-To: hjl@localhost.lucon.org
From: David Mosberger <davidm@napali.hpl.hp.com>
Date: Fri, 13 Jun 2003 00:00:39 -0700
To: "H. J. Lu" <hjl@lucon.org>
Cc: davidm@napali.hpl.hp.com
Subject: readelf question
X-Mailer: VM 7.07 under Emacs 21.2.1
Reply-To: davidm@hpl.hp.com
X-URL: http://www.hpl.hp.com/personal/David_Mosberger/

Hi HJ,

Another toolchain question: with the latest 2.5 kernel, coredumps will
cover the kernel shared library describing the gate page (aka "gate
DSO").  Unfortunately, readelf -a prints a warning message when
reading such coredumps:

$ readelf -a core
readelf: Error: Unable to seek to 24180 for symbols
readelf: Error: Unable to seek to 24330 for dynamic string table
readelf: Error: Unable to seek to start of dynamic informationELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              CORE (Core file)
  Machine:                           Intel IA-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         10
  Size of section headers:           0 (bytes)
  Number of section headers:         0
  Section header string table index: 0

There are no sections in this file.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  NOTE           0x0000000000000270 0x0000000000000000 0x0000000000000000
                 0x0000000000001c20 0x0000000000000000         0
  LOAD           0x0000000000004000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000004000  R      4000
  LOAD           0x0000000000004000 0x4000000000000000 0x0000000000000000
                 0x0000000000000000 0x00000000000c8000  R E    4000
  LOAD           0x0000000000004000 0x6000000000004000 0x0000000000000000
                 0x000000000000c000 0x000000000000c000  RW     4000
  LOAD           0x0000000000010000 0x6000000000010000 0x0000000000000000
                 0x0000000000004000 0x0000000000004000  RW     4000
  LOAD           0x0000000000014000 0x60000fff7fffc000 0x0000000000000000
                 0x0000000000004000 0x0000000000004000  RW     4000
  LOAD           0x0000000000018000 0x60000fffffff8000 0x0000000000000000
                 0x0000000000004000 0x0000000000004000  RW     4000
  LOAD           0x000000000001c000 0xa000000000020000 0x0000000000000000
                 0x0000000000004380 0x0000000000004380  R      10000
  DYNAMIC        0x000000000001c510 0xa000000000020510 0x0000000000000000
                 0x0000000000000140 0x0000000000000140  R      8
  IA_64_UNWIND   0x000000000001c4c8 0xa0000000000204c8 0x0000000000000000
                 0x0000000000000048 0x0000000000000048  R      8

Dynamic segment at offset 0x1c510 contains 15 entries:
  Tag        Type                         Name/Value
 0x000000000000000e (SONAME)             0x47
 0x0000000000000004 (HASH)               0xa0000000000200e8
 0x0000000000000005 (STRTAB)             0xa000000000020330
 0x0000000000000006 (SYMTAB)             0xa000000000020180
 0x000000000000000a (STRSZ)              97 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000070000000 (IA_64_PLT_RESERVE)  0x0 -- 0x18
 0x0000000000000003 (PLTGOT)             0x0
 0x0000000000000007 (RELA)               0x0
 0x0000000000000008 (RELASZ)             0 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffc (VERDEF)              0x000000006ffffffd (VERDEFNUM)          2
 0x000000006ffffff0 (VERSYM)              0x0000000000000000 (NULL)               0x0

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.

Notes at offset 0x00000270 with length 0x00001c20:
  Owner		Data size	Description
  CORE		0x00000478	NT_PRSTATUS (prstatus structure)
  CORE		0x00000088	NT_PRPSINFO (prpsinfo structure)
  CORE		0x00000ed0	NT_TASKSTRUCT (task structure)
  CORE		0x00000800	NT_FPREGSET (floating point registers)

Even though it reports that seeks to small addresses failed, in fact what
it's doing is trying to seek to bad file offsets::

$ strace ./readelf -a /nue/tmp/core 2>&1 | fgrep lseek|fgrep "= -1"
lseek(3, 11529215046068617216, SEEK_SET) = -1 EINVAL (Invalid argument)
lseek(3, 11529215046068617216, SEEK_SET) = -1 EINVAL (Invalid argument)
lseek(3, 11529215046068617216, SEEK_SET) = -1 EINVAL (Invalid argument)

where 11529215046068617216 = 0xa000000000024000.

I suspect what readelf ought to be doing is read the program headers
until it finds a segment that covers the desired virtual address, then
pick up the file offset from the program header.

However, I don't know enough about readelf to know whether this would
impact other things negatively.

Do you think this is something that could be fixed?

Thanks,

	--david

----- End forwarded message -----

Re: [davidm@napali.hpl.hp.com: readelf question]

[Nick Clifton]

Hi David,

> Another toolchain question: with the latest 2.5 kernel, coredumps
> will cover the kernel shared library describing the gate page (aka
> "gate DSO").  Unfortunately, readelf -a prints a warning message
> when reading such coredumps:

Is it possible for you to generate a *small* example core file which
demonstrates this problem and post it to the list ?  If not, could you
make one available for retrieval via ftp/http ?

Cheers
        Nick
        

Re: [davidm@napali.hpl.hp.com: readelf question]

[David Mosberger]

Hi Nick,

>>>>> On Tue, 17 Jun 2003 09:09:35 +0100, Nick Clifton <nickc@redhat.com> said:

  Nick> Hi David,
  >> Another toolchain question: with the latest 2.5 kernel, coredumps
  >> will cover the kernel shared library describing the gate page (aka
  >> "gate DSO").  Unfortunately, readelf -a prints a warning message
  >> when reading such coredumps:

  Nick> Is it possible for you to generate a *small* example core file which
  Nick> demonstrates this problem and post it to the list ?  If not, could you
  Nick> make one available for retrieval via ftp/http ?

Certainly.  I meant to do that with the original report, but seem to
have forgotten... ;-(

Anyhow, I now attached two files:

 core-static.gz	compressed core file for a statically linked app doing abort()
 core-static.gz	same app but dynamically linked

It doesn't seem to make much of a difference whether the file is
statically or dynamically linked, but I thought it would be best to
cover both cases.

Please let me know if you need anything else.

Thanks,

	--david

Attachment:
core-static.gz
Description: core-static.gz
Attachment:
core-dynamic.gz
Description: core-dynamic.gz

Re: [davidm@napali.hpl.hp.com: readelf question]

[Andrew Cagney]

David,

I'm guessing that ``gate page'' is vsyscall page?  Whats the Linux 
kernel status on this one?

Last I heard was a kernel patch to make auxv info available in the core 
file, and via the /proc and ptrace interfaces.

Thing is, if that's done, those extra memory sections can go back to 
being extra memory sections (and everything becomes much simpler).

Andrew

Re: [davidm@napali.hpl.hp.com: readelf question]

[David Mosberger]

>>>>> On Tue, 17 Jun 2003 15:26:35 -0400, Andrew Cagney <ac131313@redhat.com> said:

  Andrew> David, I'm guessing that ``gate page'' is vsyscall page?

Yes.  To be precise: on ia64, the gate page serves a similar purpose
as on x86 the vsyscall page.  (ia64 linux doesn't actually support
virtual syscalls; instead, there are lightweight syscalls, which have
similar performance but aren't restricted to user-mode execution).

  Andrew> Whats the Linux kernel status on this one?

They're in the 2.5 tree now (both on x86 and ia64).

  Andrew> Last I heard was a kernel patch to make auxv info available
  Andrew> in the core file, and via the /proc and ptrace interfaces.

Yes: auxv, core, and ptrace are there.  I don't think /proc support is
there.  Not sure if Roland is planning to do something about that.

  Andrew> Thing is, if that's done, those extra memory sections can go
  Andrew> back to being extra memory sections (and everything becomes
  Andrew> much simpler).

I don't have much of a preference myself.  I'm sure Roland has thought
much more about the user-level parts of the support than I have
(though I do like the idea of being able to get symbol and library
info for the kernel DSO(s); not sure how you'd do that with plain
memory sections).

	--david

Re: [davidm@napali.hpl.hp.com: readelf question]

[Roland McGrath]

> Roland, do you know anything about this?

I don't know off hand what precisely is readelf's confusion.  I do know all
about the slightly odd format of current Linux's ELF core files.  The
recent change that seems to confuse readelf is that a core file has some
new phdrs other than PT_NOTE and PT_LOAD.  It has a PT_DYNAMIC pointing to
the .dynamic section of the kernel-supplied DSO image in the dead process's
address space.  Similarly there is a PT_IA_64_UNWIND (on ia64) or
PT_GNU_EH_FRAME (on x86, maybe later others too).  The p_vaddr fields
correctly identify the user addresses where these things were found in the
live process.  Unless there is a bug, the p_offset fields correctly
identify where they were stored in the core file.  It seems to me readelf
must have a bug in its interpretation of the headers.  I can take a look.


Roland


> H.J.
> ----- Forwarded message from David Mosberger <davidm@napali.hpl.hp.com> -----
> 
> Delivered-To: hjl@localhost.lucon.org
> From: David Mosberger <davidm@napali.hpl.hp.com>
> Date: Fri, 13 Jun 2003 00:00:39 -0700
> To: "H. J. Lu" <hjl@lucon.org>
> Cc: davidm@napali.hpl.hp.com
> Subject: readelf question
> X-Mailer: VM 7.07 under Emacs 21.2.1
> Reply-To: davidm@hpl.hp.com
> X-URL: http://www.hpl.hp.com/personal/David_Mosberger/
> 
> Hi HJ,
> 
> Another toolchain question: with the latest 2.5 kernel, coredumps will
> cover the kernel shared library describing the gate page (aka "gate
> DSO").  Unfortunately, readelf -a prints a warning message when
> reading such coredumps:
> 
> $ readelf -a core
> readelf: Error: Unable to seek to 24180 for symbols
> readelf: Error: Unable to seek to 24330 for dynamic string table
> readelf: Error: Unable to seek to start of dynamic informationELF Header:
>   Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
>   Class:                             ELF64
>   Data:                              2's complement, little endian
>   Version:                           1 (current)
>   OS/ABI:                            UNIX - System V
>   ABI Version:                       0
>   Type:                              CORE (Core file)
>   Machine:                           Intel IA-64
>   Version:                           0x1
>   Entry point address:               0x0
>   Start of program headers:          64 (bytes into file)
>   Start of section headers:          0 (bytes into file)
>   Flags:                             0x0
>   Size of this header:               64 (bytes)
>   Size of program headers:           56 (bytes)
>   Number of program headers:         10
>   Size of section headers:           0 (bytes)
>   Number of section headers:         0
>   Section header string table index: 0
> 
> There are no sections in this file.
> 
> Program Headers:
>   Type           Offset             VirtAddr           PhysAddr
>                  FileSiz            MemSiz              Flags  Align
>   NOTE           0x0000000000000270 0x0000000000000000 0x0000000000000000
>                  0x0000000000001c20 0x0000000000000000         0
>   LOAD           0x0000000000004000 0x0000000000000000 0x0000000000000000
>                  0x0000000000000000 0x0000000000004000  R      4000
>   LOAD           0x0000000000004000 0x4000000000000000 0x0000000000000000
>                  0x0000000000000000 0x00000000000c8000  R E    4000
>   LOAD           0x0000000000004000 0x6000000000004000 0x0000000000000000
>                  0x000000000000c000 0x000000000000c000  RW     4000
>   LOAD           0x0000000000010000 0x6000000000010000 0x0000000000000000
>                  0x0000000000004000 0x0000000000004000  RW     4000
>   LOAD           0x0000000000014000 0x60000fff7fffc000 0x0000000000000000
>                  0x0000000000004000 0x0000000000004000  RW     4000
>   LOAD           0x0000000000018000 0x60000fffffff8000 0x0000000000000000
>                  0x0000000000004000 0x0000000000004000  RW     4000
>   LOAD           0x000000000001c000 0xa000000000020000 0x0000000000000000
>                  0x0000000000004380 0x0000000000004380  R      10000
>   DYNAMIC        0x000000000001c510 0xa000000000020510 0x0000000000000000
>                  0x0000000000000140 0x0000000000000140  R      8
>   IA_64_UNWIND   0x000000000001c4c8 0xa0000000000204c8 0x0000000000000000
>                  0x0000000000000048 0x0000000000000048  R      8
> 
> Dynamic segment at offset 0x1c510 contains 15 entries:
>   Tag        Type                         Name/Value
>  0x000000000000000e (SONAME)             0x47
>  0x0000000000000004 (HASH)               0xa0000000000200e8
>  0x0000000000000005 (STRTAB)             0xa000000000020330
>  0x0000000000000006 (SYMTAB)             0xa000000000020180
>  0x000000000000000a (STRSZ)              97 (bytes)
>  0x000000000000000b (SYMENT)             24 (bytes)
>  0x0000000070000000 (IA_64_PLT_RESERVE)  0x0 -- 0x18
>  0x0000000000000003 (PLTGOT)             0x0
>  0x0000000000000007 (RELA)               0x0
>  0x0000000000000008 (RELASZ)             0 (bytes)
>  0x0000000000000009 (RELAENT)            24 (bytes)
>  0x000000006ffffffc (VERDEF)              0x000000006ffffffd (VERDEFNUM)          2
>  0x000000006ffffff0 (VERSYM)              0x0000000000000000 (NULL)               0x0
> 
> There are no relocations in this file.
> 
> There are no unwind sections in this file.
> 
> No version information found in this file.
> 
> Notes at offset 0x00000270 with length 0x00001c20:
>   Owner		Data size	Description
>   CORE		0x00000478	NT_PRSTATUS (prstatus structure)
>   CORE		0x00000088	NT_PRPSINFO (prpsinfo structure)
>   CORE		0x00000ed0	NT_TASKSTRUCT (task structure)
>   CORE		0x00000800	NT_FPREGSET (floating point registers)
> 
> Even though it reports that seeks to small addresses failed, in fact what
> it's doing is trying to seek to bad file offsets::
> 
> $ strace ./readelf -a /nue/tmp/core 2>&1 | fgrep lseek|fgrep "= -1"
> lseek(3, 11529215046068617216, SEEK_SET) = -1 EINVAL (Invalid argument)
> lseek(3, 11529215046068617216, SEEK_SET) = -1 EINVAL (Invalid argument)
> lseek(3, 11529215046068617216, SEEK_SET) = -1 EINVAL (Invalid argument)
> 
> where 11529215046068617216 = 0xa000000000024000.
> 
> I suspect what readelf ought to be doing is read the program headers
> until it finds a segment that covers the desired virtual address, then
> pick up the file offset from the program header.
> 
> However, I don't know enough about readelf to know whether this would
> impact other things negatively.
> 
> Do you think this is something that could be fixed?
> 
> Thanks,
> 
> 	--david
> 
> ----- End forwarded message -----

Re: [davidm@napali.hpl.hp.com: readelf question]

[Andrew Cagney]

> On Tue, 17 Jun 2003 15:26:35 -0400, Andrew Cagney <ac131313@redhat.com> said:
> 
> 
>   Andrew> David, I'm guessing that ``gate page'' is vsyscall page?
> 
> Yes.  To be precise: on ia64, the gate page serves a similar purpose
> as on x86 the vsyscall page.  (ia64 linux doesn't actually support
> virtual syscalls; instead, there are lightweight syscalls, which have
> similar performance but aren't restricted to user-mode execution).
> 
>   Andrew> Whats the Linux kernel status on this one?
> 
> They're in the 2.5 tree now (both on x86 and ia64).

Ya!  Signs of sanity!  Shame no one thought to mention that here :-(

>   Andrew> Last I heard was a kernel patch to make auxv info available
>   Andrew> in the core file, and via the /proc and ptrace interfaces.
> 
> Yes: auxv, core, and ptrace are there.  I don't think /proc support is
> there.  Not sure if Roland is planning to do something about that.

I think it was in the patch?

>   Andrew> Thing is, if that's done, those extra memory sections can go
>   Andrew> back to being extra memory sections (and everything becomes
>   Andrew> much simpler).
> 
> I don't have much of a preference myself.  I'm sure Roland has thought
> much more about the user-level parts of the support than I have
> (though I do like the idea of being able to get symbol and library
> info for the kernel DSO(s); not sure how you'd do that with plain
> memory sections).

The discussion is in the archives.

The auxv provides the address of the start of vsyscall page.  GDB can 
then use that to fudge up a bfd describing those memory contents.  This 
has several important properties:

- GDB always uses the AUXV address.  That way GDB uses a single 
consistent and robust mechanism on both core files and live processes.

- GDB needs the AUXV anyway.  With out it, GDB would be forced to rely 
on heuristics when trying to determine the address of the vsyscall page 
in an already running process (it can't trust the stack).

So, while at first sight, having the core headers describe the syscall 
page symbol tables appears useful, it turns out to be less so.  Should 
it be pulled?

Andrew

Re: [davidm@napali.hpl.hp.com: readelf question]

[Roland McGrath]

>   Andrew> Last I heard was a kernel patch to make auxv info available
>   Andrew> in the core file, and via the /proc and ptrace interfaces.
> 
> Yes: auxv, core, and ptrace are there.  I don't think /proc support is
> there.  Not sure if Roland is planning to do something about that.

To clarify, I think what David's saying (and what I think is the case) is
that access to these memory regions via core dumps and ptrace does work
just like any other user address, and that the startup-time aux vector on a
process's stack contains AT_SYSINFO_EHDR to tell the process the location.

The piece that still remains missing is gdb finding out where the DSO is,
i.e. the AT_SYSINFO_EHDR value of a traced process.  For that, I've
proposed a new /proc/PID/auxv virtual file and a new NT_AUXV note in core
dumps (these match exactly what Solaris provides).  I posted a patch to
implement this in Linux 2.5 to lkml on May 15; it was met with resounding
silence.  Pushing that patch has not been top priority since then, since
this issue affects gdb only with 2.5 kernels and so is not an imminent
concern for the Red Hat products I work on.  

After posting that patch, I realized it had a leak.  I didn't bother to
follow up with the corrected patch immediately, since my posting of the
first patch had failed to solicit any response of any kind even on the
question of the interface.  I would be happy to dust off that patch and
send it to you, post it again, or send it anywhere else that would increase
the likelihood of getting some response about it.  If Linux kernel folks
are happy enough with the interface but not with the implementation, I
would be glad to rewrite it as requested.  

>   Andrew> Thing is, if that's done, those extra memory sections can go
>   Andrew> back to being extra memory sections (and everything becomes
>   Andrew> much simpler).

I don't really understand what this comment means from its content.  The
special page(s) the kernel provides for the vsyscall/gate DSO are already
normal regions of memory as far as access via ptrace, /proc, and ocre dumps
is concerned.  I can guess from Andrew's past comments that he is in fact
talking about the auxv access feature, and trying to say that he believes
having that simplifies the interpretation of core files as opposed to using
the core files' new phdrs for that (something that is in fact trivial and
I've already implemented).  

In prior discussion, it was the clear conclusion that gdb hackers' highest
preference is for the /proc/PID/auxv+NT_AUXV kernel interface being added.
I have repeatedly made clear that I am happy to implement whatever
combination of things jibes best with the preferences of Linux kernel
hackers and gdb hackers.  So far we have no input whatosever on what the
preferences from the kernel side might be.

> I don't have much of a preference myself.  I'm sure Roland has thought
> much more about the user-level parts of the support than I have
> (though I do like the idea of being able to get symbol and library
> info for the kernel DSO(s); not sure how you'd do that with plain
> memory sections).

We have discussed it in great detail on the gdb list.
Check the archives.


Thanks,
Roland

Re: [davidm@napali.hpl.hp.com: readelf question]

[David Mosberger]

>>>>> On Tue, 17 Jun 2003 13:44:40 -0700, Roland McGrath <roland@redhat.com> said:

  Roland> The piece that still remains missing is gdb finding out
  Roland> where the DSO is, i.e. the AT_SYSINFO_EHDR value of a traced
  Roland> process.  For that, I've proposed a new /proc/PID/auxv
  Roland> virtual file and a new NT_AUXV note in core dumps (these
  Roland> match exactly what Solaris provides).

Sounds reasonable to me.  Is /proc/PID/auxv really needed, though?
Isn't it easy enough to get to the aux vector from the initial stack
pointer (which gdb could catch from /proc/PID/stat).

  Roland> I posted a patch to implement this in Linux 2.5 to lkml on
  Roland> May 15; it was met with resounding silence.

That may not mean much.  Clearly it makes no sense to implement half a
solution to the problem and given that the first half is in, I don't
expect any issues in getting the rest (or some alternative) in.

Andrew Morton is very good at collecting misc. patches, providing
feedback, and feeding them on to Linus, so you might want to talk to
him (please do cc me, too; I don't have much time to work on this
myself, but I do want to make sure the ia64 portion stays in sync).

	--david

Re: [davidm@napali.hpl.hp.com: readelf question]

[Daniel Jacobowitz]

On Tue, Jun 17, 2003 at 01:44:40PM -0700, Roland McGrath wrote:
> >   Andrew> Last I heard was a kernel patch to make auxv info available
> >   Andrew> in the core file, and via the /proc and ptrace interfaces.
> > 
> > Yes: auxv, core, and ptrace are there.  I don't think /proc support is
> > there.  Not sure if Roland is planning to do something about that.
> 
> To clarify, I think what David's saying (and what I think is the case) is
> that access to these memory regions via core dumps and ptrace does work
> just like any other user address, and that the startup-time aux vector on a
> process's stack contains AT_SYSINFO_EHDR to tell the process the location.
> 
> The piece that still remains missing is gdb finding out where the DSO is,
> i.e. the AT_SYSINFO_EHDR value of a traced process.  For that, I've
> proposed a new /proc/PID/auxv virtual file and a new NT_AUXV note in core
> dumps (these match exactly what Solaris provides).  I posted a patch to
> implement this in Linux 2.5 to lkml on May 15; it was met with resounding
> silence.  Pushing that patch has not been top priority since then, since
> this issue affects gdb only with 2.5 kernels and so is not an imminent
> concern for the Red Hat products I work on.  
> 
> After posting that patch, I realized it had a leak.  I didn't bother to
> follow up with the corrected patch immediately, since my posting of the
> first patch had failed to solicit any response of any kind even on the
> question of the interface.  I would be happy to dust off that patch and
> send it to you, post it again, or send it anywhere else that would increase
> the likelihood of getting some response about it.  If Linux kernel folks
> are happy enough with the interface but not with the implementation, I
> would be glad to rewrite it as requested.  

Send me a copy of the update, please.  I'm going to push another
debug-related patch to Linus this week anyway.  He's been pretty good
about taking patches lately.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [davidm@napali.hpl.hp.com: readelf question]

[Andrew Cagney]

>>>>>> On Tue, 17 Jun 2003 13:44:40 -0700, Roland McGrath <roland@redhat.com> said:
> 
> 
>   Roland> The piece that still remains missing is gdb finding out
>   Roland> where the DSO is, i.e. the AT_SYSINFO_EHDR value of a traced
>   Roland> process.  For that, I've proposed a new /proc/PID/auxv
>   Roland> virtual file and a new NT_AUXV note in core dumps (these
>   Roland> match exactly what Solaris provides).
> 
> Sounds reasonable to me.  Is /proc/PID/auxv really needed, though?
> Isn't it easy enough to get to the aux vector from the initial stack
> pointer (which gdb could catch from /proc/PID/stat).

The inital stack, like anything else, can be corrupted.  GDB's asking 
for a definitive source.  This raised in the original thread.

>   Roland> I posted a patch to implement this in Linux 2.5 to lkml on
>   Roland> May 15; it was met with resounding silence.
> 
> That may not mean much.  Clearly it makes no sense to implement half a
> solution to the problem and given that the first half is in, I don't
> expect any issues in getting the rest (or some alternative) in.
> 
> Andrew Morton is very good at collecting misc. patches, providing
> feedback, and feeding them on to Linus, so you might want to talk to
> him (please do cc me, too; I don't have much time to work on this
> myself, but I do want to make sure the ia64 portion stays in sync).

Roland, yes, I'm suggesting that only simple loadN sections be created - 
would simplify the core dump code.

Andrew