Hi John,
On Thu, 2009-11-12 at 10:14 +1000, John Williams wrote:
On Wed, Nov 11, 2009 at 2:01 AM, Steven J. Magnani
<steve@xxxxxxxxxxxxxxx> wrote:
I've finished porting my noMMU kernel to 2.6.31 and believe I've adapted
my uClibc to the ABI changes (typedefs, system call changes,
SA_RESTORER, etc.) in that release. Most things run fine, which is a
great improvement over my initial port attempt that crashed and burned.
What I see now (and have ever since 2.6.30) is that quitting the 'top'
program (the procps one, not the busybox one) crashes the entire system.
If I comment out the calls to sigaction() in top.c, I can quit the
program just fine (as long as it's running at the serial console) and
the system stays up. The system still crashes if I try to quit a 'top'
running in a telnet session, which I think is a separate issue.
Has anyone else running 2.6.3x encountered similar problems, or can
confirm this behavior?
I remember when I did some work to bring uClibc up to 0.9.30.1, that
MicroBlaze sighandling had bit-rotted somewhat in the uclibc.org
trees, because they'd changed the internal structure and made fairly
mechanical and incorrect attempts to bring microblaze forward.
I'm still working with 0.9.27, if that's an issue. I have the 0.9.30
tarball, I'll look it over.
I'll dig out some patches that may help.
Thanks!!
I noticed that 2.6.31 made some changes to Microblaze signal handling
that bring it more in line with the generic kernel code. Were there also
problems that were being addressed by those changes?
I think more likely is the change to sighandling internals in uClibc.
We didn't have to do anything magical to glibc for example, to get the
new sighandling in place for the MMU variant.
It seems to be a problem in uClibc's __libc_sigaction(). If my 'top'
program goes in there at all, the system crashes when 'top' exits.
That's true even if I change the function so it returns immediately. I
suspect scribbling on the program stack, but can't find the culprit.
Could it be a gcc "weak_alias" thing?