Ryan Fleury's banner

Ryan Fleury

@rfleury • 25,457 subscribers

RJF // @dgtlgrove // Making RAD Debugger at @radgametools in @epicgames (opinions my own)

Shorts

This is a huge bang-for-buck improvement you can add to your UIs.

This is a huge bang-for-buck improvement you can add to your UIs.

157,606 görüntüleme

So many programs need a tab open in order to keep a window open, and it is a really annoying design trend. It makes more sense, and it is much nicer to use, to allow empty windows.

So many programs need a tab open in order to keep a window open, and it is a really annoying design trend. It makes more sense, and it is much nicer to use, to allow empty windows.

157,358 görüntüleme

In RADDBG, the "Step Out" command has been upgraded to support block stepping! It now lets you step through blocks, out of loops, or (the traditional behavior) out of function frames.

In RADDBG, the "Step Out" command has been upgraded to support block stepping! It now lets you step through blocks, out of loops, or (the traditional behavior) out of function frames.

27,882 görüntüleme

Almost fully ported the renderer to OpenGL during the last bit of the day This is not for Windows

Almost fully ported the renderer to OpenGL during the last bit of the day This is not for Windows

31,075 görüntüleme

Huge upgrade to loading speeds coming soon, especially with DLL-heavy codebases like UE! The primary reason PDB -> RDI conversion (or PDB parsing in debuggers more generally) is a big bottleneck in startup time is because they must be converted/parsed/loaded _serially_. This may seem surprising, since intuitively it'd seem like they can be converted/parsed/loaded/etc. in parallel. This is not true in the general case due to breakpoints, and how they relate to an API like `LoadLibrary`, and how it translates into debug events. When a debuggee runs `LoadLibrary`, the debugger will receive a debug event informing the debugger that the associated module was loaded. Any time a debug event is sent to the debugger, the debuggee stops running entirely. This is so that the debugger can make decisions about how the debuggee should proceed. For example, if I have a breakpoint on `foo.c:123`, that file name and line number can only be correctly interpreted (meaning resolved into code addresses) using debug information. The debugger only knows about that debug information from the PDB - without it, that file/line combo is meaningless. But importantly, the debugger cannot *resume* the debuggee until it has resolved that breakpoint - otherwise the debuggee may execute code which *would've* hit the breakpoint, *if* it were resolved in time. So, the debugger needs to ensure that all breakpoints are fully resolved before resuming. This is a correctness detail that everyone has to pay for, basically because `LoadLibrary`s are received one-at-a-time. Obviously, if it were instead an API like `LoadLibraries`, then the debugger could prepare all of the debug info in one batch before resuming - but it doesn't know what that batch would be, given just an initial `LoadLibrary`. This is unfortunate, because *generally* you are not debugging the code loading a bunch of DLLs, but the debugger can't really know that. (It is probably a good idea to provide a `raddbg_load_libraries` API at some point, so that we can resolve this issue on the debuggee side). In any case, RADDBG now resolves breakpoints much more quickly by avoiding 99% of debug info conversion work to do a common case of breakpoint resolution - you might call this "breakpoint disqualification". Basically, if a breakpoint is set, and we can quickly determine that that breakpoint's information (file location, expression, condition, etc.) *cannot apply* to some module's debug info - more quickly than doing a *full* PDB -> RDI conversion (which entails a full parse & a bunch of work) - then we can simplify the very common case in DLL-heavy cases: you put a breakpoint on `foo.c:123`, when 99% of the DLLs do not have any line info for that file, so the debugger can resume *knowing* that breakpoint will not resolve within that file. In this demo video, you can see I place a breakpoint that only resolves within the executable's debug info - it does not resolve within any of the 100 DLLs that are loaded serially. Within the `Modules` tab, you can see that as I run the target, most of the debug info is not loaded initially, even though the debuggee is running. That debug info is loading in parallel, as the debugger knows it does not need to wait for that debug info to be prepared for this breakpoint.

Huge upgrade to loading speeds coming soon, especially with DLL-heavy codebases like UE! The primary reason PDB -> RDI conversion (or PDB parsing in debuggers more generally) is a big bottleneck in startup time is because they must be converted/parsed/loaded _serially_. This may seem surprising, since intuitively it'd seem like they can be converted/parsed/loaded/etc. in parallel. This is not true in the general case due to breakpoints, and how they relate to an API like `LoadLibrary`, and how it translates into debug events. When a debuggee runs `LoadLibrary`, the debugger will receive a debug event informing the debugger that the associated module was loaded. Any time a debug event is sent to the debugger, the debuggee stops running entirely. This is so that the debugger can make decisions about how the debuggee should proceed. For example, if I have a breakpoint on `foo.c:123`, that file name and line number can only be correctly interpreted (meaning resolved into code addresses) using debug information. The debugger only knows about that debug information from the PDB - without it, that file/line combo is meaningless. But importantly, the debugger cannot resume the debuggee until it has resolved that breakpoint - otherwise the debuggee may execute code which would've hit the breakpoint, if it were resolved in time. So, the debugger needs to ensure that all breakpoints are fully resolved before resuming. This is a correctness detail that everyone has to pay for, basically because `LoadLibrary`s are received one-at-a-time. Obviously, if it were instead an API like `LoadLibraries`, then the debugger could prepare all of the debug info in one batch before resuming - but it doesn't know what that batch would be, given just an initial `LoadLibrary`. This is unfortunate, because generally you are not debugging the code loading a bunch of DLLs, but the debugger can't really know that. (It is probably a good idea to provide a `raddbg_load_libraries` API at some point, so that we can resolve this issue on the debuggee side). In any case, RADDBG now resolves breakpoints much more quickly by avoiding 99% of debug info conversion work to do a common case of breakpoint resolution - you might call this "breakpoint disqualification". Basically, if a breakpoint is set, and we can quickly determine that that breakpoint's information (file location, expression, condition, etc.) cannot apply to some module's debug info - more quickly than doing a full PDB -> RDI conversion (which entails a full parse & a bunch of work) - then we can simplify the very common case in DLL-heavy cases: you put a breakpoint on `foo.c:123`, when 99% of the DLLs do not have any line info for that file, so the debugger can resume knowing that breakpoint will not resolve within that file. In this demo video, you can see I place a breakpoint that only resolves within the executable's debug info - it does not resolve within any of the 100 DLLs that are loaded serially. Within the `Modules` tab, you can see that as I run the target, most of the debug info is not loaded initially, even though the debuggee is running. That debug info is loading in parallel, as the debugger knows it does not need to wait for that debug info to be prepared for this breakpoint.

17,527 görüntüleme

Videos

Anya Rossi

sweetdream.ai

SweetDream.ai•Sponsored•Livecam

Watch Anya Live

Anya is streaming live right now! Join her private show and enjoy exclusive content.

Exclusive private shows

1.2k viewers online

Private Show

Join now for exclusive access

Free preview available • Premium content

I'm not sure who needs to hear this, but this is how long a modern program should take to launch, and how much memory it should be using

I'm not sure who needs to hear this, but this is how long a modern program should take to launch, and how much memory it should be using

61,977 görüntüleme • 3 gün önce

This is not a real company

This is not a real company

4,422,113 görüntüleme • 9 ay önce

Panel zooms: temporarily move a panel to occupy a full window without destructively modifying your layout!

Panel zooms: temporarily move a panel to occupy a full window without destructively modifying your layout!

31,416 görüntüleme • 4 gün önce

New video: Making A Bare Metal N64 ROM This is the first in a series of videos on exploration of N64 programming from first principles. Preview of the first few minutes:

New video: Making A Bare Metal N64 ROM This is the first in a series of videos on exploration of N64 programming from first principles. Preview of the first few minutes:

69,480 görüntüleme • 1 ay önce

Basic native desktop UI integration on Linux (file pickers etc.), + "immediate-mode program installation". It is important to me that distribution of RAD Debugger binaries is as simple as possible, so I keep everything packaged as a single standalone executable. But some systems, like the default Ubuntu environment, require extra files in order to "install" an application (e.g. so that they show up when searching in the program launcher, or to show their icons in the desktop environment UIs). Other similar "installation" steps exist on Windows, for example. Installation and uninstallation has always felt to me like a bunch of unnecessary work, which is why on Windows, people package "installers" and "uninstallers" as extra utilities, which wrangle all of the extra crap that a program needs to be "installed". But the important thing to the user is, obviously, just a single boolean: is the program "installed", or is it not? So it seemed to me that the simplest way to offer this functionality was to expose a checkbox as a regular program setting, found in the regular program UI. When it is checked, RADDBG ensures all of the appropriate configuration files are written. When it is unchecked, it ensures all of those files are deleted. Thus, you just get the single binary, run it, and optionally check the box if you want extra integration into your desktop environment.

Basic native desktop UI integration on Linux (file pickers etc.), + "immediate-mode program installation". It is important to me that distribution of RAD Debugger binaries is as simple as possible, so I keep everything packaged as a single standalone executable. But some systems, like the default Ubuntu environment, require extra files in order to "install" an application (e.g. so that they show up when searching in the program launcher, or to show their icons in the desktop environment UIs). Other similar "installation" steps exist on Windows, for example. Installation and uninstallation has always felt to me like a bunch of unnecessary work, which is why on Windows, people package "installers" and "uninstallers" as extra utilities, which wrangle all of the extra crap that a program needs to be "installed". But the important thing to the user is, obviously, just a single boolean: is the program "installed", or is it not? So it seemed to me that the simplest way to offer this functionality was to expose a checkbox as a regular program setting, found in the regular program UI. When it is checked, RADDBG ensures all of the appropriate configuration files are written. When it is unchecked, it ensures all of those files are deleted. Thus, you just get the single binary, run it, and optionally check the box if you want extra integration into your desktop environment.

85,586 görüntüleme • 2 ay önce

“Near the zero point” — unstructured stream rambling about my excitement for N64 (M64) programming, demoscene & retro dev, LLMs / vibecoding, modern programming culture, and where useful / interesting work lies

“Near the zero point” — unstructured stream rambling about my excitement for N64 (M64) programming, demoscene & retro dev, LLMs / vibecoding, modern programming culture, and where useful / interesting work lies

90,524 görüntüleme • 2 ay önce

Left: From-scratch debug build, launching target, and stepping with RADDBG. Right: Launching target & stepping with Visual Studio 2022.

Left: From-scratch debug build, launching target, and stepping with RADDBG. Right: Launching target & stepping with Visual Studio 2022.

708,835 görüntüleme • 2 yıl önce

Many people have commented on the relatively smaller sizes, faster startup time, better performance, and smoother interactivity of projects like the RAD Debugger or File Pilot. The “secret” is literally just writing things sensibly from scratch. Just stop importing things, and actually solve the problem yourself.

Many people have commented on the relatively smaller sizes, faster startup time, better performance, and smoother interactivity of projects like the RAD Debugger or File Pilot. The “secret” is literally just writing things sensibly from scratch. Just stop importing things, and actually solve the problem yourself.

232,912 görüntüleme • 10 ay önce

More excellence

More excellence

182,894 görüntüleme • 9 ay önce

And here is editing a 1+ GB text file using this mechanism

And here is editing a 1+ GB text file using this mechanism

54,772 görüntüleme • 3 ay önce

Easy to miss if you get lost in the noise in online programming discourse, but straightforward programming in a systems language like C can provide high performance, modern UI, without much hassle.

Easy to miss if you get lost in the noise in online programming discourse, but straightforward programming in a systems language like C can provide high performance, modern UI, without much hassle.

117,648 görüntüleme • 8 ay önce

Step 4 of bare metal M64 programming: Reading N64 controller input states via the JoyBus protocol over the Serial Interface (SI).

Step 4 of bare metal M64 programming: Reading N64 controller input states via the JoyBus protocol over the Serial Interface (SI).

26,107 görüntüleme • 1 ay önce

“native has nothing to offer” No, you’ve just either never bothered to seriously try it, or you just suck.

“native has nothing to offer” No, you’ve just either never bothered to seriously try it, or you just suck.

91,342 görüntüleme • 7 ay önce

Step 3 of bare metal M64 programming: SI interrupt handling, used for JoyBus device detection. Controller input state next!

Step 3 of bare metal M64 programming: SI interrupt handling, used for JoyBus device detection. Controller input state next!

23,999 görüntüleme • 1 ay önce

Here’s ~9 GB (close to 500M lines). I clipped out the initial load time (it’s something like 30 seconds, a lot of it is single threaded — should improve a lot on the next pass). But once the file is loaded, edits remain ~instant.

Here’s ~9 GB (close to 500M lines). I clipped out the initial load time (it’s something like 30 seconds, a lot of it is single threaded — should improve a lot on the next pass). But once the file is loaded, edits remain ~instant.

36,194 görüntüleme • 3 ay önce

Source-inline display of auto watch expressions, computed by determining which addresses are read from / written to by a particular range of instructions, and mapping that back to variables via location info within debug into.

Source-inline display of auto watch expressions, computed by determining which addresses are read from / written to by a particular range of instructions, and mapping that back to variables via location info within debug into.

45,111 görüntüleme • 5 ay önce

Getting closer.

Getting closer.

76,408 görüntüleme • 11 ay önce

Palettes should be first class functionality provided by the operating system for any program.

Palettes should be first class functionality provided by the operating system for any program.

85,588 görüntüleme • 1 yıl önce

I just asked Cursor to remake the Visual Studio debugger but better, look at what it made🤯🤯 Programmers are cooked... 💀

I just asked Cursor to remake the Visual Studio debugger but better, look at what it made🤯🤯 Programmers are cooked... 💀

77,105 görüntüleme • 1 yıl önce

Someone mentioned to me that they missed a file tree view in the RAD Debugger, so they could easily browse their project folder hierarchy. I then realized I had inadvertently already implemented it in the watch window.

Someone mentioned to me that they missed a file tree view in the RAD Debugger, so they could easily browse their project folder hierarchy. I then realized I had inadvertently already implemented it in the watch window.

30,842 görüntüleme • 6 ay önce