Question about MASM - Why "CC" filler?

[ohaya]

Hi,

I'm rather new to assembly programming.  Actually, maybe 'old', as I haven't done much for a long while, but am trying to get back into it.

So, anyway, I am using MASM, and starting with some simple programs, compiling and running them, and also, working with a debugger to look at them, and I have what might be a kind of stupid question  :'(. 

I was looking at the code produced, and comparing it to the source, and I noticed that it's putting "fillers" (not sure what to call them) containing 0xCC in certain places.

For example, here's one program (from Kip Irvine's web site):

TITLE MASM Template                  (main.asm)

INCLUDE Irvine32.inc
.data
myMessage BYTE "MASM program example",0dh,0ah,0

.code
main PROC
   call Clrscr

   mov    edx,OFFSET myMessage
   call WriteString

   exit
main ENDP

END main

which produced the following:

00401000  CC CC CC CC CC E9 06 00  00 00 CC CC CC CC CC CC  ¦¦¦¦¦T...¦¦¦¦¦¦
00401010  E8 22 00 00 00 BA 00 50  40 00 E8 11 0F 00 00 6A  F"...¦.P@.F¤..j
00401020  00 E8 E4 0F 00 00 CC CC  CC CC CC CC CC CC CC CC  .FS¤..¦¦¦¦¦¦¦¦¦¦
00401030  50 E8 DA 0F 00 00 C3 55  8B EC 83 C4 E8 60 80 3D  PF+¤..+Uï8â-F`Ç=

[I've bolded the "fillers" that I'm asking about.]

I guess I have a couple of questions:

1) Why is it using 0xCC?  Is there any particular reason for choosing that value vs. something else?

2) In the hex dump above, there are 5 bytes containing 0xCC, starting at 00401000, followed by a JMP to the "main Proc".  From googling, it looks like a 0xCC opcode is an "INT 3"?  What are these for? 

As I said, sorry if these are dumb questions, but I hope someone can explain.

Thanks in advance,
Jim

[Mark Jones]

Hi Jim, welcome to the MASM32 forum.

1) Why is it [filling] using 0xCC?  Is there any particular reason for choosing that value vs. something else?

Yes, MASM does this on purpose. The "0xCC" character, if code execution ever branches into one of these on its own, translates to an INT 3 instruction. The INT 3 instruction is a so-called "Debugger Trap," meaning it throws an error to halt the program (on purpose.) The "0xCC" filler is commonly placed between procedures and code for two reasons. One, to cause a "fault" if the code somehow lands where it shouldn't. And second, to align the start of each procedure to specific addresses (usually a power of two.) Generally, the processor "likes" code to be on even memory boundaries, and may slow down when trying to deal with odd addresses. MASM knows this, and automagically inserts these characters as needed to produce fast and robust code.

[ohaya]

Hi,

I think that I've figured out why the 1st 5 bytes might be 0xCC (INT 3).  I had compiled/assembled in DEBUG.

I changed the MASM configuration to compile in RELEASE, and those 1st 5 bytes of 0xCC are gone, and so is the JMP.  Instead there's now a CALL/0xE8 at 401000.

I'm still curious about my 1st question though.  It's still putting 0xCC in for fillers, although it looks like that's just for ALIGN (in my MASM source).

Thanks,
Jim

[ohaya]

Hi Jim, welcome to the MASM32 forum.

1) Why is it [filling] using 0xCC?  Is there any particular reason for choosing that value vs. something else?

Yes, MASM does this on purpose. The "0xCC" character, if code execution ever branches into one of these on its own, translates to an INT 3 instruction. The INT 3 instruction is a so-called "Debugger Trap," meaning it throws an error to halt the program (on purpose.) The "0xCC" filler is commonly placed between procedures and code for two reasons. One, to cause a "fault" if the code somehow lands where it shouldn't. And second, to align the start of each procedure to specific addresses (usually a power of two.) Generally, the processor "likes" code to be on even memory boundaries, and may slow down when trying to deal with odd addresses. MASM knows this, and automagically inserts these characters as needed to produce fast and robust code.

Mark,

It looks like our posts crossed :), but thanks!  That confirms the part that I just posted about, and also explains the other part (about why 0xCC for the ALIGN.

Later,
Jim