HN user

lzybkr

78 karma
Posts1
Comments26
View on HN

Not 5 levels, but I once wrote debug visualizers for a compiler using funceval (the visualizer uses the debugger to run code in the target process).

I think I once had to debug the debugger debugging the compiler compiling itself which felt like another really weird kind of recursion.

Curl Wttr.in 6 years ago

PowerShell can be shorter by 1 character for this use case:

  irm wttr.in
irm is an alias for Invoke-RestMethod which is similar to Invoke-WebRequest but better for non-html responses like json or plain text.

I guess it's time to reread Starship and the Canoe - a great book about Freeman's nuclear weapon powered spaceship and his son George's interest in building boats. I thoroughly enjoyed it 25+ years ago.

Rust 1.32 released 8 years ago

Visual C++ has the __debugbreak() intrinsic function.

If you have JIT debug enabled, you will be prompted to attach your debugger to the process when hitting such a breakpoint.

12 Factor CLI Apps 8 years ago

With PSReadLine, you can change that:

  Set-PSReadLineOption -EditMode Emacs
Or
  Set-PSReadLineKeyHandler -Key Tab -Function Complete

I'm optimistic about binaries providing completions, I think we'll see more of that as tools adopt frameworks like https://github.com/clap-rs/clap or https://pypi.org/project/argcomplete/ which can provide completions for your favorite shell.

But I do think many important/useful binaries will never provide completions, or provide sub-par completion that people will want to improve, so we can't ever count on completions from binaries.

Recently I've been thinking some about how the LSP (https://microsoft.github.io/language-server-protocol/) might be useful for a CLI. A readline implementation could use something like a LSP for syntax coloring and completion.

Imagine having a consistent editing in your favorite shell, repl, and editor.

I have no specific insight to this patch, but I do have personal experience binary patching a popular Microsoft product.

My patch was to the VC++ compiler nearly 20 years ago. We had source, and my fix was also applied to the source (which I'd imagine is still there today), but a binary patch also made sense in the short term.

The binary that I patched was used to build another important Microsoft product, and this bug was found late in the product cycle where any compiler change was risky.

We weren't 100% confident we had the exact sources used to build that version of the compiler (git would have been handy then), we only knew, plus or minus one day, what the sources where.

After carefully evaluating the binary patch versus the risk of building from uncertain source, the binary patch was taken to reduce risk.

I'm no reverse engineer, but this was a pretty interesting exercise in RE even though I had sources. I had no symbols, and the binary was optimized so that functions were not contiguous, cold paths were moved to the end of the binary. Just finding the code I needed to patch was not easy.

The code review was fun - a dozen or so compiler engineers reviewed the change on paper printouts - the most thorough review I've had in my career, and the only one that used paper.

To the best of my knowledge, this binary was never used to build anything other than that specific version of the product which I won't name - not that it matters really, the product is still in use, but that version is unlikely to be in use anywhere anymore.

I take it back, the VC++ options are C++ only (faulty memory, it's been too long.)

There is a warning I added which does work in C (https://msdn.microsoft.com/en-us/library/t7khkyth.aspx). As I recall, this warning is sometimes useless (unless it's been improved upon), so it's best to turn it on only when you're investigating packing.

You make a good point about C code not compiling as C++ as much as it used to, but that's probably less true for VC code.

And I should point out - often, for the purposes of tuning, you can extract just what you need from some code, get that small chunk of code compiling as C++, and leverage your compiler's dumps.

Last thing - debuggers also know the layout of your objects. windbg's 'dt' command can show you the object layout - I'm sure other debuggers have a similar command.

I implemented the VC++ options - they work in C.

I have no experience with the others, I've just briefly read about them and assume they are similar. If they don't work in C and you would find the dumps useful, try compiling as C++.

Most commonly used compilers have options to help find padding that is possibly not needed.

VC++ has a couple of undocumented (but well known and discussed) options /d1reportAllClassLayout and /d1reportSingleClassLayout.

GCC has -fdump-class-hierarchy

CLANG has -cc1 -fdump-record-layouts

I tried a Solowheel a couple years ago with a group of other unicyclists. I thought we'd all have no troubles the first try, but it did take a couple minutes to get the hang of it. I thought the training wheels actually slowed down our learning.

After a bit, most of us had no troubles going up and down a very steep hill or going full speed on the flats.

It was fun to try, but I couldn't see buying one - too expensive. I also found my shin bones hurt after an hour of messing around.