C compiler output

[hobomatic]

Just debugging hello world without debugging symbols, and it looks like the linker separates some segments of executable code with sections filled with int3. Is this accidental, intentional, or is this not coming from the linker? If its intentional, what is the rationale behind it? Just curious. I thought maybe it was some sort of code injection/reversing protection or something. Neither of which I know much about, but both of which I am actively researching.

[Grincheux]

INT 3 (0xCC) is used for aligment.
I never found that Pelle's C Compiler created may code segments.
Try to tell the linker to create the map file.

[TheRaven]

I thought int 3 looked familiar - opcode for debugger interrupt at the CPU level; albeit your system's without symbols as it may be run with the debugger int 3 would still be present in accordance with the debugger's policy/design. It seems as though this int 3 deal would give the debugger a moment to check for any error return values. Int 3 is pretty widely used, if not exclusively, during steeping in code; just an FYI if it matters.

Generally padding at the low level is performed using NOP often referred to as no op like a null opcode that does nothing and the CPU ignores purposely. GCC loves NOP (don't know whether that's saying something or not :-)

yeah, if your running a debug exec without symbols the int 3 would still be present in most cases for the debugger at significant regions in your executable file's code regardless (kind of standard practice).