<story><title>Give me 15 minutes and I&apos;ll change your view of GDB (2015) [video]</title><url>https://www.youtube.com/watch?v=PorfLSr3DDI</url></story><parent_chain><item><author>yen223</author><text>I used to think GDB was a tool with the most broken interface I&amp;#x27;ve ever seen, and which requires arcane commands to do the most trivial of debugging things.&lt;p&gt;I still do, but I used to too.&lt;p&gt;That early dig against Windows was particularly funny. There&amp;#x27;s no way I would pick that over Visual Studio&amp;#x27;s debugging tools.</text></item></parent_chain><comment><author>userbinator</author><text>I agree that gdb&amp;#x27;s syntax is ridiculous, having come from a background of DOS DEBUG and WinDbg, but what irritates me more are the implementations of certain functionality:&lt;p&gt;- No way to get a 16-column (bytes+ASCII) standard hexdump. This is functionality that even the most basic debugger should have, yet it&amp;#x27;s missing from gdb.&lt;p&gt;- &amp;quot;disassemble&amp;quot; command is next to useless.&lt;p&gt;- If you write &amp;quot;b 0x12345&amp;quot; intending to set a breakpoint at address 0x12345, it doesn&amp;#x27;t work. An unnecessary and nonsensical extra asterisk is needed (which makes it look like it&amp;#x27;s retrieving 4&amp;#x2F;8 bytes from 0x12345, and using &lt;i&gt;that&lt;/i&gt; as the address of the breakpoint.)&lt;p&gt;- Starting gdb with a binary and passing arguments to it --- you&amp;#x27;d expect it to be smart enough to realise that anything after the executable name should be the arguments to the debuggee and not the debugger, but it isnt.&lt;p&gt;I don&amp;#x27;t use gdb often, but when I do, it&amp;#x27;s usually the option of last resort.</text></comment>
<story><title>Give me 15 minutes and I&apos;ll change your view of GDB (2015) [video]</title><url>https://www.youtube.com/watch?v=PorfLSr3DDI</url></story><parent_chain><item><author>yen223</author><text>I used to think GDB was a tool with the most broken interface I&amp;#x27;ve ever seen, and which requires arcane commands to do the most trivial of debugging things.&lt;p&gt;I still do, but I used to too.&lt;p&gt;That early dig against Windows was particularly funny. There&amp;#x27;s no way I would pick that over Visual Studio&amp;#x27;s debugging tools.</text></item></parent_chain><comment><author>fest</author><text>I could agree with you on gdb&amp;#x27;s user interface. However, working on embedded hardware, plain gdb and it&amp;#x27;s architecture-specific forks|variants have been the least fiddly things to use.&lt;p&gt;The most recent examples I&amp;#x27;ve stumbled upon were System Workbench for STM32 and Atollic Studio debugging relatively recent STM32F7 series. When the debugging from IDE doesn&amp;#x27;t work,  it&amp;#x27;s very hard to see where the problem is (is the hardware interface service started? with the correct parameters? does it have access to hardware USB device? did it even succeed flashing the firmware?)</text></comment>