Comments on: A Few Things You Didn’t Know about Signals in Linux Part 1

By: Extending ltrace to make your Ruby/Python/Perl/PHP apps faster at time to bleed by Joe Damato

Thu, 08 Oct 2009 12:00:49 +0000

[...] A software breakpoint is just a series of bytes (0xcc on the x86 and x86_64) that raise a debug interrupt (interrupt 3 on the x86 and x86_64). When interrupt 3 is raised, the CPU executes a handler installed by the kernel. The kernel then sends a signal to the process that generated the interrupt. (Want to know more about how signals and interrupts work? Check out an earlier blog post: here) [...]

By: Enabling BIOS options on a live server with no rebooting at time to bleed by Joe Damato

Mon, 06 Jul 2009 13:02:48 +0000

[...] know, I know. I skipped Part 2 of the signals post (here’s Part 1 if you missed it). Part 2 is coming [...]

By: Spencer

Spencer — Wed, 24 Jun 2009 00:12:57 +0000

Yea but what happens when you get a triple fault?!

PS what's up dude =)

By: Paul

Paul — Tue, 16 Jun 2009 23:37:02 +0000

Just wanted to let you know that I find your blog fascinating. Having recently started digging back into C after several years, I have rediscovered my appreciation and awe for the people who really *know* this stuff. Your blog is providing encouragement, and some selected places for me to dip my toe in.

More! :D

By: khigia

khigia — Tue, 16 Jun 2009 07:35:54 +0000

Nice post! thanks.
So code handler get arguments through CPU register instead of the stack … is it to make sure the handler is called even in case of stack overflow of other weird case?