On Tue, Feb 21, 2012 at 10:52:50AM +0000, Will Deacon wrote:

On Tue, Feb 21, 2012 at 10:10:52AM +0000, Russell King - ARM Linux wrote:

quoted

On Tue, Feb 21, 2012 at 10:00:41AM +0000, Will Deacon wrote:

quoted

On Tue, Feb 21, 2012 at 08:36:12AM +0000, Russell King - ARM Linux wrote:

quoted

Maybe no one uses a debugger for uclinux programs?

I confess to finding this by inspection rather than a debugging failure.

There is another explanation - that is no one in the uclinux world uses
mainline kernels, and this bug has been fixed ages ago in some uclinux
kernel tree.

That directly raises the question of the value of having the uclinux
baggage in the mainline kernel if no one is using mainline kernels for
uclinux work.  If the uclinux folk aren't willing to pass up bug fixes,
then having it in mainline is, frankly, a waste of space.

I know the validation guys in ARM use mainline kernels for bringup on
MMU-less CPUs (ok, they have extra patches on top but these tend to be
platform-specific hacks since they're running on an RTL emulator. Plus they do
periodically rebase onto new release kernels.). Debugging tends to be at a
much lower level than GDB can provide though (i.e. waveforms), so this would
have gone un-noticed.

I think it's worth keeping the support, particularly in light of the recent
interest in M-class CPUs on the list.

In any case, I think we need to know whether this really is a problem or
not.  If no one has noticed that this is broken in the last 2.5 years,
that implies that no one is using this, and so there's no point either
the kernel or gdb carrying support which no one is using.

The other thing is, as this has been broken right from the start, has
gdb under uclinux even been tested?

I don't think fixing this in mainline until we know the full story behind
this is the right thing to be doing.  There's no point fixing a feature
which no one's using.