Short: EFindHit v1.2 (for Enforcer output) Author: jason@fsel.com (Jason R. Hulance) Type: dev/e Architecture: m68k-amigaos EFindHit can be used to find the line number of an Enforcer hit in an E program, given the offset information that Enforcer produces. Unlike normal FindHit programs, EFindHit reports the line numbers of hits in E modules, too (i.e., not just the main program). And it can also tell you which function the code was in. Usage ----- To use EFindHit, the main source file *must* be compiled with the LINEDEBUG or DEBUG switches. And if you want to track hits in modules used by the program, they too must be compiled with one of these switches. If you want to see the names of functions as well, then you need to use the SYM switch, too, but only on the main source file. This is especially useful for tracking hits in E internal functions. If you don't use the SYM switch when compiling your source then EFindHit cannot reliably identify hits that occur in E internal functions (it may report them as coming from the last line of one of the sources, and flag those offsets that appear to be too far beyond the last line). EFindHit takes the following arguments: EXECUTABLE/A,DEBUG/S,OFFSETS/M So, you can supply a list of offsets. Hexadecimal offsets can be specified using a leading '$' or '0x'. Without these prefixes the offset is interpreted as decimal. New to v1.2 is the DEBUG switch: see below for an illustrative example. Example ------- For example, consider the following output from Enforcer (when SegTracker is running): BYTE-READ from 00000000 PC: 7833432C USP: 7834B4B0 SR: 0004 SW: 0751 (U0)(-)(-) TCB: 7828F188 Data: 00000000 0000000D 78348FB8 7829016C 00000001 1E0CCF39 78348FB8 00000001 Addr: 00000000 7828F1E4 783343AE 7829016C 7834B6C0 7834B4B4 78019864 -------- Stck: 00000000 7829016C 78334306 783341F2 00000000 00000000 00000000 00000000 Stck: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ----> 7833432C - "xxx" Hunk 0000 Offset 00000244 Name: "Shell Process" CLI: "xxx" Hunk 0000 Offset 00000244 The interested lines are the first and last. The first line says the hit was a byte read from $00000000 (probably from dereferencing a NIL pointer). The last line says that the culprit was the program "xxx" and that the hit happened at offset $00000244. (You might also consider using the STACKCHECK option of Enforcer to get the backtrace of the call stack.) If "xxx" has been compiled with LINEDEBUG (or DEBUG) then you can run EFindHit on it to find the line number of the hit in one of the source files: 1.System:> efindhit xxx $244 EFindHit works better if you compile with the SYM option Offset $244: "xxx.e" line 5 [$242] The first line of output is a reminder that using SYM makes EFindHit work better, then the information about the offset. The trailing "[$242]" indicates the offset of the start of the code for line 5. If you've compiled "xxx" with the SYM option too, then things get a bit better: 1.System:> efindhit xxx $244 Offset $244: "xxx.e" line 5 [$242], in "fun()" [$238] This also states the function the hit occurred in, and gives the offset of the start of code for that function ($238). If you don't trust the output of EFindHit (???), then you can use the DEBUG switch to dump all the information from the executable that EFindHit uses. (If this switch is specified then any supplied offsets are ignored.) For example: 1.System:> efindhit xxx debug $00000000 *** Startup1 *** $00000196 *** End of startup1 *** $00000374 *** End of code *** $00000236 fun() $000001D2 zzz() $00000196 external() $00000284 main() $000002DA WriteF() $0000036A Char() $0000023A 14 xxx.e $00000240 15 xxx.e $00000244 16 xxx.e $00000288 22 xxx.e $0000028E 23 xxx.e $000001D6 4 zzz.e $0000019A 8 xyz.e $000001EE *** Startup2 *** $00000200 *** End of Startup2 *** The first column is the offset, the second (if present) is the line number and the last column is the name of the file, the function or another significant part of the executable. You could sort this output if you have pipes set up: 1.System:> efindhit xxx debug | sort in: out: $00000000 *** Startup1 *** $00000196 *** End of startup1 *** $00000196 external() $0000019A 8 xyz.e $000001D2 zzz() $000001D6 4 zzz.e $000001EE *** Startup2 *** $00000200 *** End of Startup2 *** $00000236 fun() $0000023A 14 xxx.e $00000240 15 xxx.e $00000244 16 xxx.e $00000284 main() $00000288 22 xxx.e $0000028E 23 xxx.e $000002DA WriteF() $0000036A Char() $00000374 *** End of code *** Now it's really easy to see where any particular offset lies... Possible output --------------- As well as complaining about errors (like you forgot to compile with LINEDEBUG), EFindHit might report: 1) Offset $244: "xxx.e" line 5 [$242], in "fun()" [$238] The offset is in the identified function in the main source. 2) Offset $200: "xyz.e" line 11 [$1E8], near EXPORTed "external()" [$196] The line number information for code in modules is more accurate than the function information, since only EXPORTed functions can be followed. So EFindHit reminds you that the code at the offset is only "near" the EXPORTed function (i.e., some point after it but before the next EXPORTed function). 3) Offset $280: E internal function "Char()" The hit has occurred in an E internal function. You probably want the backtrace in this case (the STACKCHECK option of Enforcer), so you can spot which function this was called from. 4) Offset $190: E startup code The hit has occurred outside user code, either when starting or cleaning up. This didn't ought to happen unless your code has scribbled all over the place. (These offsets will show up in the backtrace produced by the STACKCHECK option of Enforcer, as E code always starts in the startup code!) 5) Invalid offset $330: not in code part The hit didn't occur within the code of the executable being analysed. This might happen if you're running EFindHit on the wrong program or a different version from that which produced the hit. 6) No line number for offset $200 EFindHit couldn't find a line number (but might still be able to identify a function, nonetheless, and this will be reported as "in" or "near" as appropriate [assuming you've compiled with the SYM option]). Limitations ----------- There's no symbol information (currently?) for any methods or for functions which are not EXPORTed from modules. So it's not possible to put names to offsets in these bits of code (the line numbers should be sufficicient in these cases). And offsets in methods/INCBIN/other data in the main source file will be reported as being "in" the nearest function before it. The startup code recognition is pretty much specific to EC v3.2e. It's likely to change in future... Have fun!