I have NEVER gotten GDB to work on any platform, with any JTAG dongle. NOT EVER!
So, I don't even bother. If the plan is to start with an mbed compatible board, you might as well use the online mbed compiler and a whole lot of printf() statements. You can write a lot of code with the stuff that's provided. If you use the original mbed LPC1768, you can include networking in your projects by adding just a MAGJACK. The toolchain works on a lot of the other mbed compatible platforms as well.
In the STM32F4 world, some of the boards are mbed compatible (listed at the web site) and you can use the online toolchain. Again, with a lot of printf()s.
You can also use STM32F ST-Link to program the board and make a connection to GDB. Once again, I haven't gotten it to work but, according to the chosen few, it does work.
You can certainly use Eclipse as an IDE without using GDB or even with it, if you can get it to work. I just downloaded Eclipse Neon with the GNUARM plug-in and it works very well. It really is intended to target the STM boards but it will do the others if it is set up right.
As to GDB? Well, if you don't put bugs IN your program, you won't have to get them OUT of your program. I did all he single stepping I ever want to do back in the days of the 8085. What a colossal waste of time!
Unless things have changed, the IAR toolchain isn't free or unrestricted. One thing about the GNU toolchain, you aren't limited to only a few hundred lines of code or a couple of K of object code.
I'm not sure what to think about STs automagic setup program, STM32CubeMX. It seems pretty nice and it generates a lot of code plus a nice report BUT... If I build my project off of their code, what happens when I have to add one more gadget? I get a whole new framework and I somehow have to move my code into theirs. DIFF, I suppose. Either that or I have to initially copy their code into mine and then, somehow, do that over again. One way of the other, I expect to lose my edits. I better get it right the first time!
The other thing that is disappointing with the boards listed at mbed is that they all use a lot of the peripheral pins that I would rather use for something else. I need 3 full blown USARTS with flow control, I need two SPI channels with NSS and, I would consider using their onboard Ethernet. I spent most of yesterday looking for a board that had these peripherals. Not a chance! In every case, some onboard peripheral jammed up the configuration.
If I were looking for 'simple', I would start with the original 'mbed' (LPC1768) with the project board as a base and use the online toolchain (plus a bunch of printf()s.