Ghidra1

This is one of those cases where we would need gzf in state prior to your invoking the F action to properly diagnose. There is insufficient detail to attempt to...

Sample, which does appear to replicate your reported issue, has the first byte at SUB_07000020 as part of the body for the preceeding function at FUN_07000008 which is tripping-up the...

I had been wanting to add this capability for some time but am faced with a dilema. The API has issues in that it can currently allow for duplicate field...

Moving forward would it make sense when adding/changing components to force name uniqueness (e.g., adding a one-up suffix) and eliminate throwing DuplicateNameException where currently done. In addition, a new getComponentByName...

My feeling is returning an array complicates matters and supporting duplicate names seems unneccessary. It seems in general if it occurs it would be rare and/or unintentional. Certainly, C/C++ source...

> getComponentByName could return null and log error if a duplicate field name is detected Revision: leaning towards returning first component found with given name. Error would only be logged...

For AVR8: Functions should not be defined in the `codebyte` space. I believe all code and functions should be defined in the `code` space only. The byte-mapped `codebyte` space exists...

Are you able to share you code (*.gzf) so we can better understand your situation which has caused the use of `code` and `codebyte` space to become entangled for the...

This is related to #2577.

You should try to determine what is setting `void` as the return type. If it is unknown it should be returning `undefined`. The decompiler removes quite a bit of dead...