Thanks for sharing that, Jon! Sorry I missed it.The following is nothing to do with embedded, just rambling about some evolution I witnessed while working for computer OEMs. Eons (almost four decades back) my work made me cross paths with somebody who had juiced up a debugger so the disassembler was cognizant of the symbols available from the object files (what the compiler put out for each compiled source file) and he was specifically using it for reverse engineering, but mainly to track down bugs in code he couldn't get source for (apropos last night's talk, from what I gather). But debuggers (forebears of IDEs) worth anything could disassemble binaries and decent and a very old compiler option was to inter leave source and corresponding assembler. Fast forward to the early 90s when a certain Finish student with name starting with L spent many hours reverse engineering the SunOS kernel to figure how to do many things he needed to put in his code to show Tannenbaum how pitiful his orginal Minix was. (Sun was never bothered by that, as far as I know: dollars to donuts Bill Joy did whatever he could to determine how existing code worked, but of course UC Berkeley had a Bell Unix source license ). Vaguely around that time, when Linux was still in diapers (e.g. 35 floppies with the Slackware distro) Motorola juiced up their compilers to do optimization of executable files. This involved a wild form of parsing of binary instructions in fully linked executable files. Their "binary optimizer" could do a lot of clever things to boost performance. Very vaguely around this time compilers started peeking at whole sets of compilation units to do extremely clever things like automagic inlining. This was around the time the 386 and 486 snuck up on Moto and other RISC chip vendors, blowing their doors off, then the Pentium strapped on the FTL and took off like Han Solo's pirate ship and forced competitors back to the drawing board.Pete -------- Original message --------From: Jon Wolfe via TriEmbed <[email protected]> Date: 3/9/20 11:34 PM (GMT-05:00) To: [email protected] Subject: Re: [TriEmbed] TriEmbed March Meeting Tonight presentation on Ghidra was really cool. I didn’t know much about Ghidra before, but I’m definitely going to check it out. The question came up about what hardware architecture platforms it supported for analysis. According to Wikipedia, it supports a ton of CPU architectures, including PIC 8 bit, AVR, MSP430, 6502, 8051, 68k! (And of course ARM too). The only platform I am likely to run into these days that was missing from Wikipedia description was espressif. I did some searching and it looks like there is work on a plugin to support it. I have several cheap IoT type devices on my home automation that run off esp8266’s it would be a fun exercise to see if my Chinese WiFi power strips are phoning the motherland with information about when I’m turning my fish tank lights off and on… From: Brian Grawburg via TriEmbedSent: Wednesday, March 4, 2020 1:01 PMTo: TriEmbedSubject: [TriEmbed] TriEmbed March Meeting
_______________________________________________ Triangle, NC Embedded Computing mailing list
To post message: [email protected] List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org TriEmbed web site: http://TriEmbed.org To unsubscribe, click link and send a blank message: mailto:[email protected]?subject=unsubscribe
