Hi,
I am using Macro Assembler 6.11
ml /omf /c /Zi /Zd program.asm
link /segments:500 program.obj
I am using Microscope debugger, but I can't find any debugging info inside the program.
Any advices for me?
Thanks
Jack
Printable View
Hi,
I am using Macro Assembler 6.11
ml /omf /c /Zi /Zd program.asm
link /segments:500 program.obj
I am using Microscope debugger, but I can't find any debugging info inside the program.
Any advices for me?
Thanks
Jack
Sounds like that debugger can't handle the debug info. Reading this http://social.msdn.microsoft.com/For...6-541c7575e5fa it seems that you have CodeView in that package so try with that instead.
fatal error L1101: invalid object module
Object file offset: 800fd Record type: 9c
I got this error when I tried to include /CO [CODEVIEW] into the program, it is a link time error
Thanks
Jack
Hm, are you sure you're using the proper linker? I mean, is it possible that your path's are setup in a wrong way?
I'm unable to try things out myself unfortunately. I tried to find that masm version at microsoft but failed (only found version 8).
In addition to what S_M_A posted...
What makes you think you need the /omf option? Perhaps the linker doesn't like that. Also, the /SEGMENTS:500 looks pretty suspicious to me. Aside from the fact that it's quite a lot (you know, we already discussed that... ;)), neither the MASM 6.1. manual (not 6.11, however) I have here nor the help of the LINK 10.00 that came with VC++ 2010 lists an option like that.
Also, just to make sure, you did specify the option /CO on the linker command line, didn't you? Then that's not "included into the program".
@S_M_A
I am using the following version
Macro Assembler 6.14.8444
Link16. 5.12.8078
I checked on the web, i doubt that the program is too big for the assembler/linker to work on.
@Eri
I use /omf because I am working on a DOS program ;), and yes, i also need /segments:500 because it is a single disassembly in one module. I include the /CO switch, then the message comes up, otherwise, it doesn't happen.
Thanks
Jack
I've written dozens of assembly language programs for DOS without ever using that option (as I said, in fact I didn't know yet it even existed). However, that's some time ago and I think I was using some MASM 6.x, not sure which version exactly, though. Have you tried to simply let MASM and LINK figure out how to store their data by themselves?Quote:
Originally Posted by lucky6969b
Though my statement about the /omf option in post #5 was factually right, I had looked in the wrong place: Of course /omf is an ML option, and ML 10.00 does know it. Note, though, that MSDN states:
Quote:
Originally Posted by MSDN
I already told you that just that a disassemler output is a syntactically correct assembly language module does not necessariliy mean it can simply be re-assemled and linked as-is. And I have some notion yours requires a lot of modifications...Quote:
Originally Posted by lucky6969b
I'd suppose that option to control the linker's output, not its input, and in the error message you quoted the linker complains about an invalid input .obj file. OTOH the linker may simply skip some records in the input .obj file without that option specified.Quote:
I include the /CO switch, then the message comes up, otherwise, it doesn't happen.
Just what S_M_A already recommended in post #4: Make sure you're not unintentionally mixing incompatible versions of ML and LINK.
At any rate, I doubt you'll get much useful symbolic information from just re-assembling a disassembler output file anyway. Why don't you simply debug the original executable (or whatever that is)?
Yes, I think I may want to debug the original program. But I've another question, when an interrupt handler has been setup in the TSR, how do you catch the interrupt when the "satellite" application calls the TSR? I ask because I can't have both programs running in the debugger at the same time while CV hasn't got anything like "break on interrupt xxh"
Any ideas?
Thanks
Jack
Right, you can't "break on interrupt xxh", but nothing stops you from placing a breakpoint in the TSR's interrupt handler. Be careful, though, about intercepting anything that might directly or indsirectly be called by the debugger itself. What happens when you do intercept something used by the debugger may depend on how well the debugger is prepared to handle that case. I haven't used CV for a very long time, so I can't tell you how it behaves in that situation. Also, intercepting hardware interrupts is particularly delicate, since they're often time-critical.
Taking the common INT 21h as an example, the rule of thumb is this: Don't intercept the entire interrupt, instead intercept individual functions of the interrupt. And the more exotic the function you intercept is, the better, best probably is intercepting a function that's even private to your application.