I just tried on a microcontroller target.

Some instructions cause a ghidra.pcode.exec.PcodeExecutionException but can be manually skipped.

I can get to the same stopping points as a commercial simulator, but nothing is displayed in the Stack window in the Ghidra debugger and single stepping ignoring side effects (mostly for cpsie/cpsid/isb/dsb/msr/mrs op codes) takes 10 or 15 seconds for each skipped instruction. Watches on complex variable types (ListItem_t *) are clearly displayed wrong (value { 38 }) and I'd prefer watches to disappear when they're not in scope. I must be doing something wrong because I can step through the machine code but would prefer to step through each C++ line without using line-by-line breakpoints, and I don't know if that exists or how to set it up.

Right now, it's easier for me to use a commercial debugger/simulator; it shows the call history, variables are displayed properly once I import their structure, browsing SRAM is fast/intuitive, MCU peripheral registers are displayed/changed on a single screen with a few clicks or keystrokes (even after importing the SVD into Ghidra), op codes don't need to be skipped (so the processor handles the stack, privilege states, and core/system registers correctly).

Also, the default debugger windows in Ghidra are bonkers. The entire left side shows meaningless data. The right side has tabs for windows I'd like to see simultaneously (memory and decompilation). I'd also rather have multiple child windows for different memory ranges, since FreeRTOS and application variables are interspersed in the code but separated in RAM. The bottom panel is useless for me except for Stack (which is empty) and Watches. On a laptop, the whole UI is cramped. It's easy to change this, but I'd rather just have a useful workflow as an opinionated default.

When I can export what I've manually decompiled to DWARF, I'm more comfortable in a commercial Arm debugger than in gdb or anything that looks/feels like an Eclipse IDE debugger.

There's a lot of potential. That is obvious. I do wonder if I'm missing something; if changing the emulator/backend or the right tool setting will unlock nirvana. I also feel like I'm dropping the ball by not opening issues, but I'm sure there are plenty of Ghidra users trying to analyze Arm Cortex who have the same stumbling blocks as me but perhaps more free time.

I've been chipping away at recreating source for a dumped FreeRTOS binary for about a year using Ghidra and Trace32. (Disclosure: I work on Trace32.)

I wanted to implement something like https://github.com/neuviemeporte/mzretools (the tool for reversing F15SE, a DOS game) but I would need to port all of that tooling to an Arm cross-compiler and accept it will never produce a 1:1 binary in my case. (There's evidence the original was built with IAR which I will not be buying solely for a hobby project.)

Ghidra (especially after using BSim to load all of the NXP demos and some TI library code for adjacent ICs) is extremely useful at getting the entire structure: library functions, data types, tasks, queues, I2C/USB comm, pin setup, data locations, etc. You can re-code the flash part easily, but SRAM/stack is all zeros. The code that fills SRAM uses pointer math and some loops and is generally unreadable on its own. I tried the Ghidra simulator, but it didn't work out of the box on Arm microcontroller code.

Trace32 makes it easy to load the raw binary into an Arm simulator and step through all the way to the IDLE task, but there's no high-level listing. You just have to detect if you're in a loop and look at the loop address in Ghidra to see what holds you back. Without a simulation model (which I do not have---at least not outside of work) you have to manually jump past a few spots where the board waits for an acceptable status flag from a clock source, etc., and then manually call SysTick_Handler once, but the SRAM is eventually filled with appropriate data. Once you have a stack, you can start picking out which FreeRTOS macro parameters were set and figuring out the size and type of vendor-created structures which then streamlines further Ghidra analysis. Beyond that, you can't use RTOS awareness without symbols, so unless you write a script to import these from Ghidra, a more insightful view of the binary remains out of reach.

The analysis has been a LOT of looking back and forth between the simulator (which shows a hex address and machine code) and the Ghidra decompilation listing; it is a bit like getting Don Quixote verbally read to you, one letter at a time. Anytime there's a I2C_Master_Transmit(), you need to comb through datasheets for DSP settings and the various I2C-linked chip registers. It's a USB product (with multiple endpoints) so I use Wireshark and Python to check the decompiled USB application code and identify valid packet data that are never sent by the vendor software.

DWARF can be imported and exported in Trace32, so exporting symbols created in Ghidra as DWARF would vastly simplify my workflow (as would having a real model of the NXP chip and/or dumping the bootloader binary and secrets from a production device).

I'll definitely check out this project, as well as ghidra2dwarf linked by nneonneo.

I miss trace32.

I miss how everything is in its place.

I miss the number of times I've wondered if some functions could be combined and toy delight they worked wonderfully.

Just writing in to say I'm a fan.

Ugly. Goofy. Uninspired.

Awful color palettes and far too many shades of each hue. If the bluetooth icon is lit but the containing button is unlit, is bluetooth active or not? The icons are some of the worst ever; just a monochrome abstract mess. Of the 12 shown in the quick settings example, I cannot recognize 4 of them. Blurred background in the notification shade is worse than both a solid color or a fully transparent background. The former emphasizes privacy and information clarity; the latter doesn't interrupt whatever you're doing. Blurred means you can't refer to the app screen while looking at a notification but nosey passersby (or clever application of the right deconvolution on a screenshot) can get a general sense of what you were doing.

Too much padding. Alignment is often not thoughtful. Many of the shapes are just strange. The use of different border radii on adjacent elements---notably at 1:09, but also nearly everywhere else---is like a lazy eye or snaggletooth. The "Clear all" notifications button is too big (i.e. easy to accidentally touch) but also an uncomfortable aspect ratio. This is significantly worse on the watch.

Animations totally unnecessary and often not visually intuitive. (Wtf is that jellyfish circle progress meter at timestamp 1:03?) Not every user wants a "cascading droplet effect" or "springy animation" or "happy moments". It's visually noisy. Shape morphing is sea sickness via OLED. It's the kid who can't stop tapping a pencil on a desk and loudly coughing up phlegm all day.

Font is informal and overused. The variable font has more than 10 axes and becomes unreadable at the extremes.

I predict there will be two camps: the developers who don't change their apps at all and those that lean too heavily into this ridiculousness. There will be virtually no tasteful Material Expressive apps.

The promise is "customizable", but it's not USER customizable. You're at the mercy of each app developer. You can't change those awful notification buttons, overly rounded dialogs, bubble images EVERYWHERE.

And it's always so ... busy. I want my most used portable appliance---my vessel of knowledge, communication, and productivity---to just stay still and quiet and do the tasks I request without trying to affect my emotional state and distract me with its unnecessary wiggling and weaving, less identifiable icons, inefficient presentation of info, and irritating nested clickable elements.

Complaining about it is pissing into the wind. Google has committed far too much in this newest terrible design evolution to try something wildly different and actually bold (a la Guardians of the Galaxy) or to return to a simple & timeless no-frills appearance, and there are plenty of users who can't get enough of the "Easter-colored cooked pasta taped to a leaf blower nozzle" aesthetic.

In other words: I don't like it.

It doesn't help that the Play Store has no effective way to browse recently developed apps or to filter searches in any meaningful way whatsoever.

Couple that with the Indiana Jones boulder chase known as the Target API Level Requirement plus needing to log in every six months or risk getting your Google Dev account permanently deactivated and then needing to relaunch all of your apps under a new namespace.

A handful of apps I use come from small companies (5 to 40 employees) who should not have a dedicated mobile dev on their payroll. The apps do not pose a security risk (as they don't use internet/network features) and don't need to be updated as they are feature-complete. One such company just pulled all of their free apps and now has a contractor charge users for worse functioning redesigns.

and syntax highlighting

If you use a shotgun for this sort of thing, there's not a high risk of serious injury---particularly if you obey gun safety standards e.g. identifying everything in line with your target to the full range of your ammo.

The interesting theoreticals happen when a drone has a legitimate purpose (a drone owned by the county used for property appraisal, law enforcement, control of invasive species, etc.) or when someone causes serious harm/damage to a third party or even starts a fire from a falling drone.

Per Florida legislation: Reasonable expectation of privacy means circumstances under which a reasonable person would believe that he or she could fully disrobe in privacy, without being concerned that the person’s undressing was being viewed, recorded, or broadcasted by another---inside a house, bathroom, changing room, dressing room, tanning booth, etc.

(They keep falling back on 'reasonable'. I'm not sure I could describe the border between a reasonable and unreasonable person.)

For non-lawyers, "reasonable" is the law word for, first, whatever the judge thinks is OK (often despite being unable to articulate a clear standard for present and future analysis) in order to allow the case to advance to trial; next, whatever the finder of fact at trial (whether jury or judge) thinks is right (again, often despite being unable to articulate a standard, and almost never explaining the reasoning) in order to make a decision; and finally, whatever the appellate court(s) think(s) about the previous decisions.

In other words, "reasonable" is a logical slush fund and an indication to decide based on gut feelings.

True, we claim that certain synthesizing explanations and precedents develop over time, but those developments, and the applications of those precedents, often continue to turn on the decision-makers' gut feelings.

It makes sense to me that the law would have to frequently refer to "reasonableness". It's hard to be absolutely rigid about human behavior. We're programmers; we know how hard it is to properly think through every possible case even in the highly confined world of software. Humans are so, so much harder. I'm OK with that.

But that makes me not OK with it when lawyers pretend that they are being rigorous. I've never seen a single Supreme Court decision that I did not consider utterly appalling -- even the ones I agree with. If they were to write "because that's what I think is reasonable" I'd have some respect for it. They call it an "opinion"; go ahead and say that.

Reasonable, as used in the law in many if not most situations, has become a contronym. Reasonableness should be rigorous: it's in the term itself (capability of being reasoned / derived through reasoning). The intent behind the term is to use logic to ascertain / derive / apply the (sometimes tacit) social rule; but many judges turn that into "I'm reasonable (i.e., I'm not unreasonable, meaning clearly wrong much of the time), and this is my decision (whether or not I explain my supposed reasons to expose them to analysis and criticism), so therefore my decisions (and the things at issue) are reasonable; or, in my view, the thing at issue was not reasonable." Of course, such reasoning is itself illogical and, in my view, therefore unreasonable.

I just threw numbers into there (population x ownership percent x replacement frequency x unit cost) to estimate the annual revenue of the smartphone market and got a few percentage points away from what the internet reports is the true value.

Because there are trig functions, this would also be nice for reverse engineering of complex parts from simple measurements (feature volumes, corner angles, cross-sectional areas)

Multimodal would be nice but not necessary.

Inverse trig functions would be interesting but complicated and not necessary.

In any case, this tool is more convenient than opening Python every time I want to estimate a range of answers.

The LKML is no gold standard.

After searching on lore.kernel.org, do you click through individual messages with such insightful subject lines as, "media: camss: Format configuration per hardware version," and, "rcar-vin: feature enhancement and fixes?" or do you read through the nested results, which on a test search related to a recent problem I had, gave me 2.5 MB of text across 74K lines?

Even then, I didn't find exactly what I wanted and would need to browse the kernel source (and will it be mainline or next?) and click through. The frontend for git.kernel.org does not have per-line blame (unless I missed it somewhere) so I have to checkout just to find the commit I want or browse the log until I find the changed line or hope that the expanded log is verbose enough to match my search term.

lkml.org is certainly no better, with no method of searching or grouping related topics.

Or... Do you refer to a third-party search engine doing the heavy lifting of indexing and deciding the relevance of a problem?

As opposed to most chat clients, where you just search and get a preview of all possible matches, and then go to that conversation. Sure, with Discord it involves opening the client and the potential for security mishaps and other problems of modern software (ads, useless features) but it is generally not difficult to search through a half-decent channel.

You get similar ease-of-use and searchability with a git repository with a half-decent frontend plus it makes it significantly easier to track proposals, changes, feature history, etc.

... except when a merge request or issue suddenly has more than 5 participants or a branch is building a new feature, where it then makes sense to take it to a chat where you get an instant notification and tight feedback loop between all participants, rather than rapid-fire updating the bug tracker and its associated merge request comments and the reported issues in a dependency's repo.

Gotta go; a coworker is asking me in the chat to push a fix to nightly.

I don't know about every Brother model. On ours, there's a key sequence you can press to reset the toner cartridge odometer letting you squeeze out toner until the text is a satisfying light grey.