Intro: How To?

[jbglaw]

Hi Klaus!

Ghidra is built, I've loaded a dumped FEPROM from a /90, loaded at 0x2004000. That's probably a dumb question somehow, but .. how do I mark some bytes as a function?

I can place labels somewhere.

I can set a type of word for the register mask.

I can disassemble the code following the register mask word properly, but that doesn't give me a proper function (which would have nice code on the side and allow me to work on the function signature.)

It seems there actually is a function command which can be used on disassembled bytes, but ... a VAXish function doesn't start at the code but two bytes earlier. And these two bytes (register mask) are not meaningfully disassembled. So: What's the trick with having a proper function (to also have its address resolved properly at the CALLS side) and not getting ugly disassembly results for the register mask?

Thanks!

[kkaempf]

Good question !

That's what goes into the .pspec and .cspec files. See here for how to build the docs.
I'm not even sure this is supported by (vanilla) Ghidra. 🤷🏻

[kkaempf]

Took another look at this problem - and I don't think this is fixable within Ghidra

• there's no code pattern to identify a start of a function
• one could search for callg or calls instructions but the target address is computed in most cases (e.g. looking at ka43a.bin)

😞

[jbglaw]

I think of this not as a problem of automatically detecting function entry addresses, but to fix the display (and generated C code) for whenever you mark something as a function. To declare some address as a function, you'd typically disassemble at that address, then mark it as a function (using keyboard shortcuts.) But there's no sense in disassembling the register mask. (Though it would be nice to show them in a decoded form.)

Is there some active Ghidra community that can advise a path to setup an address as a function, but to not have actual executeable code there?

Working with my 4000m90 ROM, once you identify some code correctly (which is easy as the ROMs start with a jump to the actual bootstrap code), it's usually quite straight forward to go from there. It's just ... totally inconvenient to not be able to mark a function as such, thus we don't get some approximate C code generated for it.

[kkaempf]

I think of this not as a problem of automatically detecting function entry addresses, but to fix the display (and generated C code) for whenever you mark something as a function. To declare some address as a function, you'd typically disassemble at that address, then mark it as a function (using keyboard shortcuts.) But there's no sense in disassembling the register mask. (Though it would be nice to show them in a decoded form.)

That might be solvable by a Ghidra script 🤔
Or by a (Java-based) extension - like this one for 8051.

Is there some active Ghidra community that can advise a path to setup an address as a function, but to not have actual executeable code there?

There's some activity on Stackoverflow. I usually raise an issue to get help.

Working with my 4000m90 ROM, once you identify some code correctly (which is easy as the ROMs start with a jump to the actual bootstrap code), it's usually quite straight forward to go from there. It's just ... totally inconvenient to not be able to mark a function as such, thus we don't get some approximate C code generated for it.

That's actually touching the boundary between the disassembler (which was my primary focus) and the decompiler (pcode). I haven't cared much about the latter :-/

[jbglaw]

I'll try to have a look. Getting Ghidra up is "just" a side project. (Indeed, it's my fist time ever using Ghidra.) When I attempted to disassemble some ROMs back in the days, I used objdump's -M entry:0xaddr option (https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=ec72cfe589400f06810a571ce4d7f45fb6e19621), but that's quite tedious work! Need to have a script to add all the discovered entry points, no commentry, ... But at least back in the day I generated some .dot output. Usually, when I found a function's entry (and end address), I fed that assembler part into some .dot generator and continued my work for that function on actual paper with a real pencil and a rubber.

Compared to that, the current state with Ghidra is a lot better! :)