You are talking about the full complement of memory in this thread, and have done so in several other threads too.

But the fact is that a very tiny fraction of 32-bit processors are making use of their full 32-bit addressing range, so there is seldom a need for the full complement of memory.

When it comes to debugging, a system designed with 16MB of RAM for normal use can normally run the debugger too without noticing the tiny fraction of extra memory needed. And having a 100Mbit/s Ethernet interface or 480Mbit USB means that you can do a lot of logging without need for huge log buffers locally.

If I am about to design a solution having 4kB RAM in the final target, I would not mind a chip with 16 or 32kB on one or two prototype boards, to allow me to add some fancy debug code. But when the final target reaches one or more MB, then the final target is normally so capable that I don't have the same need for any extra capabilities.

I try to do the majority of the debugging in my head, before downloading the firmware. Using a graphical debugger is one specific way of working, but it is not something needed. A debugger can help locating an error, but only source-code analysis can help catch the missing error handlers that a testrun with the debugger will fail to notice because the test vector did not trig the specific error case.

On the other hand, a big sytem may produce huge amounts of information. One system I have can produce 10GB of logs within a couple of hours. In a live system, I can obviously not expect that kind of data to be sent out on a lowly GPRS connection. In the end, I must from the beginning know what I'm after, in which case I can adjust any log configuration. Being used to a high-end development platform with "everything" installed would make me quite frustrated when the target I need to debug happens to be mounted on a moving vehicle, and the problem I'm after can not be reproduced in laboratory. I can't send out DHL with a GPS receiver and tell them to hunt down that vehicle and get the standard unit replaced with a development super-duper edition. It may even be worse: The problem may happen in one of maybe 500 installed vehicles distributed all over a continent, with a probability of one error condition every month. That means that every one of these 500 units must has some form of debugability as-is.

Having a device that can support of up to 4GB of flash and/or 4GB of RAM can wait until I need to develop a product that is expected to ship with that kind of requirements. And when it comes to flash, a CF, SD or USB memory can solve the multi-GB requirements with even the low-end development boards.