Inline assembly with gcc on linux

Sometimes, it's useful to test/debug at assembly level. On linux gcc provides inline assembly to directly embed assembly code into your source code. I was chasing a wierd bug in a multi thread application, the program crashed with SIGSEGV with the following information:

(gdb) bt
#0 0x00d5f3dc in pthread_join () from /lib/libpthread.so.0
#1 0x0804b51b in main (argc=140055452, argv=0x3e8) at main.cpp:214
(gdb) x/20i 0x00d5f3c0
0xd5f3c0 : push %ebp
0xd5f3c1 : mov %esp,%ebp
0xd5f3c3 : push %edi
0xd5f3c4 : push %esi
0xd5f3c5 : push %ebx
0xd5f3c6 : sub $0x28,%esp
0xd5f3c9 : call 0xd5d4fa <__i686.get_pc_thunk.bx>
0xd5f3ce : add $0xac26,%ebx
0xd5f3d4 : mov $0x3,%edi
0xd5f3d9 : mov 0x8(%ebp),%eax
0xd5f3dc : mov 0x48(%eax),%ecx <------------- SIGSEGV
0xd5f3df : test %ecx,%ecx
0xd5f3e1 : js 0xd5f4aa
0xd5f3e7 : mov $0x16,%di
0xd5f3eb : cmp 0x200(%eax),%eax
0xd5f3f1 : je 0xd5f4aa
0xd5f3f7 : mov %gs:0x8,%edi
0xd5f3fe : add $0x200,%eax
0xd5f403 : mov %eax,0x8(%esp)
0xd5f407 : lea 0xffff53b8(%ebx),%eax

The prototype of pthread_join is this: int pthread_join(pthread_t thread, void **value_ptr); Now I couldn't remember how the parameters were passed into a subroutine on the stack, exactly what's in 0x08(%ebp)? Is it thread or value_ptr. Inline assembly to the rescue:

#include < stdio.h>

int foo(int x, int y){
unsigned long int ebp;
asm("movl %%ebp, %[ebp]" : [ebp] "=m" (ebp));
printf("$ebp=%x $x=%x $y=%x\n", ebp, &x, &y);
return x+y;
}
int main(){
int x = 3, y = 4;
foo(x, y);
}

$ ./addr_t
$ebp=bfb799c8 $x=bfb799d0 $y=bfb799d4

clearly, gcc on linux passes the paramter following the C argument passing convention, that is the arguments are pushed onto stack from right to left. The stack looks like this (top is higher memory address):
$y
$x
$ret_addr

And the prelog of pthread_join creates a stack like this:
$y
$x
$ret_addr
$ebp <--------- $ebp = $esp

It's clear now that 0x08(%ebp) is the address of argment 'thread', and apparently something went wrong and 'thread' contains an invalid memory address in the crashed application.

Design and implement large software system

I personally found it very efficient to follow the following cycles to implement large software system:

1) research, see what features are required, any existing software/library that can speed up the development, what are the platforms to support, what tools should be used, etc

2) design and documentation, express your software system in clear text what it does, how it does it. Try to be as precise as possible.

3) unit testing of tools, 3rd party softwares, and libraries, this is often partially done in phase 1, but at this stage a through and in-depth unit testing framework should be employed.

4) I personally prefer developing software by component and writing unit test alone the way. Never underestimate the power of unit testing, even the simplest test can save you hours of headache.

5) packaging and integration. If design is sound and documentation is clear, software development is simply a matter of man-hour.

6) more testing.

Perl: a practical OO design of complex system

In this entry, I'll focus on code reuse design by understanding how Exporter works in a complex perl hierarchical software system. The main process daemonizes itself, then it checks its configuration file. For each item listed in the configuration file, it creates a perl object and then daemonizes it.

Entry:
Daemonize
Read config file
For each config item:
+fork-----child process---daemonize
|
+fork-----child process---daemonize
....

Each config item daemonizes and shares some common code such as new, run (main daemon loop method), etc. In C++, this is mostly likely accomplished like this:

template
class base{
public:
base(){}
run(T t){}
};

class HTTP: base{
public:
prep_http_header(){}
};

Here we use the CRTP (curious recursive template pattern) to build the hierarchy inherit base class methods run and constructor in derived class such as a HTTP protocol handler.

With perl, things are a little different:

package network::Base;
use base qw(Exporter);
our @EXPORT_OK = qw(new run);
sub new{}
sub run{}
1;

package network::HTTP;
use network::Base qw(new run);
1;

By declaring the base class an Exporter, Base module can export symbols to classes that use it. As one may soon realize, OO is quite an interesting design in perl. The language itself is very extensible and by simply exporting/importing symbols, it achieves inheritance through the 'use base' and 'Exporter' module. In fact there is nothing special about Exporter module. All that it does is injecting symbols into packages using it. Because 'Perl automatically calls the import method when processing a use statement for a module.', by declaring a Base module inheriting from Exporter, it also inherits the import method and subsequently all modules using Base module will be able to selectively choose symbols to import from Base.

the quest of free usenet news server

Wait, I thought the first rule of usenet is you don't talk about usenet. :) Anyways, usenet has been a huge source of knowledge and entertainment for me. It's been frustrating lately since my home broadband ISP decides to be smart and stopped allowing people using their news server from anywhere but home. It's time to find a free usenet news server.

http://news.aioe.org/ is the result of my quest. It's very fast, reliable and hassle-free. It's a very respectable server and I encourage you to use it and follow its user guidelines.

Introducing libsigc++

libsigc++ library captures the publisher/subscriber pattern nicely in a typesafe modular way. For example,

#include < sigc++/sigc++.h>
#include < sigc++/signal.h>
#include < sigc++/signal_base.h>
#include < iostream>
#include < string>
using std::cout;
using std::endl;

class Publisher
{
public:
    Publisher(){};

    void run() { sleep(3); signal_detected.emit("Detector news"); }

    sigc::signal signal_detected;
};

void subscriber_fptr(std::string news)
{
    cout << news << ": There are aliens in the carpark!" << endl;
}

class Subscriber : public sigc::trackable
{
public:
    Subscriber() {} ;
    void subscriber(std::string news) { cout << news << ": Aliens alert, aliens alert!" << endl; }
private:
    // ...
};

int main()
{
    Publisher mydetector;
    mydetector.signal_detected.connect( sigc::ptr_fun(subscriber_fptr) );

    Subscriber sub;   // added
    sigc::connection sub_plan = mydetector.signal_detected.connect( sigc::mem_fun(sub, &Subscriber::subscriber) ); // changed

    cout << "Subscriber subscribed to alienDector news\n";
    mydetector.run();
    cout << "Subscriber stopped subscribing to alienDector news\n";
    sub_plan.disconnect();
    mydetector.run();
    return 0;
}

Notice how closely the library embraces the publisher/subscriber pattern. It'd been perfect if the functions (connect, disconnect) were renamed to (subscribe, unsubscribe)... C# offers the same pattern with the delegation model (new keywords delegate are introduced in C# to facilitate the pattern).

In order to compile/run the sample code, install libsigc++ and libsigc++-devel packages, the compile command is:
g++ -I/usr/include/sigc++-2.0/ -I/usr/lib/sigc++-2.0/include -o sigcpp_t sigcpp_t.cpp -L/usr/lib -lsigc-2.0