Ygdrasil

요즘은 목요일 25시에 방영하는 あの日見た花の名前を僕達はまだ知らない。 (그날 본 꽃의 이름을 우리들은 아직 알지 못한다. 이하 "아노하나"로 표기) 그리고, 일요일 22시에 방영하는 花咲くいろは(꽃이 피는 첫걸음) 덕에 스트레스를 해소하며 산다.

오늘 방영분 "아노하나"는 아주 흥미진진했다. 특히 마지막 즈음에 와서는, "진작 그러지, 쪼옴!" 이라고... 다음주 금요일이 많이 기다려진다.

평소에 애니메를 볼 때 오프닝, 엔딩은 항상 건너뛰면서 본다.
그러나, "아노하나"는 엔딩의 저 장면이 아주 좋기 때문에 ("하악!" 하는 부분이다) 빠지지 않고 엔딩을 매주 보고 있다 :D

"꽃이 피는 첫걸음"은, '이게 뭐야, 진흙투성이 아수라장이 될 건가!' 하는 예감이... 전부터 있었지만, 더 강하게 들기 시작하지만, 한 회 한 회의 작화의 질이 극장판이라, 놓칠 수가 없다.

이 두 애니메가 번갈아가면서, 이번주는 얘가 더 재미있고, 지난주는 쟤가 더 재미있었고, 하면서 스트레스 해소를 톡톡히 해 주고 있다.

또 하나 더 있는데, 이건 화장실개그, 허리하학적 개그가 난무하는, 거의 성인물에 가까운 것이라 여기서 소개하기는 약간 거시기하지만,

일단, 소개하자면, 금요일 23시의 よんでますよ、アザゼルさん。(부르고 있어요, 아자젤씨) 되겠다.
말이 빠르고 저질스런 단어가 많이 쓰여서 좀 곤란하긴 하지만 (자막제작자도 한두편 만들다가 잠수탄 듯)
박장대소를 할 수 있기에 가끔 모아서 보고 있다.

아, 그리고!!! 진 2기도 보고 있는데,,, 드라마는 너무 길어서, 볼만한 여유가 나지 않아 묵혀 두고 있다.

TOC

0. No SIGBUS on x86?!
1. Why?
2. How to tell x86 to warn me an unaligned memory acess?
3. So, what? - A real world application
4. Possible worry
5. When programming for Intel's CPUs, no need to care about alignment?

0. No SIGBUS on x86?!

According to wikipedia, there are two cases where a processor generates bus error:
1. non-existent address
2. unaligned memory access.

Strangely, you may have never seen such an error on x86 processors.
Compile following code and run it on a x86 machine:

#include <stdio.h> #include <stdlib.h> #include <string.h> int main(void) { char *p; /* * malloc() always provides aligned memory. * Do not use stack variable like a[9], depending on the compiler you use, * a may not be aligned properly. */ p = malloc(sizeof(int) + 1); memset(p, 0, sizeof(int) + 1); /* making p unaligned */ p++; printf("%d\n", *(int *)p); return 0; }

You will find no problem with your program on x86 machines:

shawn.r2:~/work/aligntest$ uname -a
Linux r2 2.6.18-194.el5xen #1 SMP Tue Mar 16 22:01:26 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
shawn.r2:~/work/aligntest$ gcc a.c
shawn.r2:~/work/aligntest$ ./a.out
0
shawn.r2:~/work/aligntest$

On the contrary, if you try it on SPARC or IA64 machines, You will definitely end up with bus error:

shawn.sx1000:~/work/align$ uname -a
HP-UX sx1000 B.11.31 U ia64 1177235479 unlimited-user license
shawn.sx1000:~/work/align$ cc a.c
shawn.sx1000:~/work/align$ ./a.out
Bus error (core dumped)
shawn.sx1000:~/work/align$

shawn.v880:~/work/align$ cc a.c
shawn.v880:~/work/align$ uname -a
SunOS v880 5.10 Generic_142900-01 sun4u sparc SUNW,Sun-Fire-880
shawn.v880:~/work/align$ ./a.out
Bus Error (core dumped)
shawn.v880:~/work/align$

1. Why?

Well, my speculation is that it is because x86 processors do something to take care of this kind of unaligned memory access on microinstruction level.

Intel provides a way to switch off this feature. According to Intel's ia32 system programming guide, the EFLAGS register has a flag called AC (Alignment Check) flag. It is bit 18 in the EFLAGS register. After turning the AC flag on, you will be able to encounter with bus errors.

CPL is abbr. of Current Privilege Level. Intel's processors (x86 family) have 4 CPLS: 0, 1, 2, 3. Usually CPL 0 is used by the kernel (privileged mode), and CPL 3 is for user level processes.

2. How to tell x86 to warn me an unaligned memory acess?

Now, how to turn it on? First, you need to push the content of the EFLAGS register on the stack with PUSHF assembly instruction. And raise the bit 18 of the value on top of the stack, which is current value of EFLAGS. And then pop it back into EFLAGS register (RFLAGS for x86_64) with POPF assembly instruction. Following is the assembly code (AT&T convention):

pushf orl $0x40000, (%esp) /* (%rsp) for x86_64 */ popf

Note that if you do this on a 32bit x86, you need to use ESP register instead, as noted in the comment.
The difference between ESP and RSP is that ESP is 32-bit, and RSP is 64-bit. If your processor is x86_64, it uses RFLAGS instead of EFLAGS. You need to use your stack pointer correspondingly.

Now, insert this assembly code into the original source code :

#include <stdio.h> #include <stdlib.h> #include <string.h> int main(void) { char *p; __asm__("pushf\n" "orl $0x40000, (%rsp)\n" "popf"); /* * malloc() always provides aligned memory. * Do not use stack variable like a[9], depending on the compiler you use, * a may not be aligned properly. */ p = malloc(sizeof(int) + 1); memset(p, 0, sizeof(int) + 1); /* making p unaligned */ p++; printf("%d\n", *(int *)p); return 0; }

Behold, now you have SIGBUS on an x86 processor:

shawn.r2:~/work/aligntest$ gcc a.c
shawn.r2:~/work/aligntest$ ./a.out
Bus error (core dumped)
shawn.r2:~/work/aligntest$ uname -a
Linux r2 2.6.18-194.el5xen #1 SMP Tue Mar 16 22:01:26 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

3. So, what? - A real world application

We use a bunch of workstations at my workplace. People prefer x86 Linux systems because they offer more convenience to developers with great GNU tools. And they are faster than Solaris or HP-UX or AIX systems because systems other than x86 were bought at least 5 years ago.

But, the fact that people prefer x86 Linux systems over SUN's or IBM's systems brings a problem because x86 processors do not detect unaligned memory access. For that reason, I have constantly urged my crew to test their programs on Solaris (of course not to test them on Solaris x86). But people are not pleased to use slow and crowded Solaris machines when they have fast, new x86 Linux machines.

It would be very good if I applied this one line of assembly code to our product because it will enable programmers to detect their unaligned access to the memory even on x86 machines. It would be horribly embarrassing if our product crashed, especially because of a bus error! It implies that we do not thoroughly test our product and the company's credentials would be undermined. Happy to prevent it more easily beforehand.

4. Possible worry

Some people might be worried that turning AC flag on would have side effects on another processes running on the system. But, it is nothing to worry about, because flag register(s) is(are) in the process's context. It only affects the process that turned it on. When a context switching is to take place, the operating system pushes EFLAGS register and bunch of registers on the stack of the process that's going background, and then load the context of the process selected for the next active process. The context of the process includes EFLAGS register.

This is my speculation and I have not yet tested: if you want to enable alignment checking systemwide, you are going to want to set AC flag in the CR0 control register instead of the one in the EFLAGS register. I am not sure if it is true or not for the time, but I am going to test it tomorrow. If it were true, the system I will be testing it on might go down though :-)

----

Unfortunately, you must be in the ring 0, or CPL 0 to access CR0. That is, you can set AC flag in the CR0 only if you were in kernel module :-p. And, my speculation turned out to be true lol

----

Added 12 March, 2011:

5. When programming for Intel's CPUs, no need to care about alignment?

Intel CPUs allow unaligned access of words, double words, quad words. They don't generate GP(General Protection) exception that causes a SIGBUS signal even if an access to a memory is unaligned.

Then doesn't it make sense that programmers who work on Intel's CPU do not need to care about address alignment, right? Yes. It makes sense.

But, programmers SHOULD know of the fact that an unaligned memory access requires additional memory bus cycle even on Intel's CPUs. Intel's CPU manual says:

A word or doubleword operand that crosses a 4-byte boundary or a quadword operand that crosses an 8-byte boundary is considered unaligned and requires two separate memory bus cycles for access.

- Intel 64 and IA-32 Architectures Software Developer's Manual Volume 1, Section 4.1.1

So, it is always good practice for programmers to make every effort to use aligned memory access even on Intel's machines.

----

포스팅 날짜 변경. 원 날짜 : 2010/10/27 12:12

Since bash version 3.2, there has been a handy feature called 'tab completion'.

But with ubuntu distribution, the cool feature becomes somewhat like pain in the ass. Why? Look at following example:

shawn.ygdrasil:~/work/bash_completion$ mkdir foo
shawn.ygdrasil:~/work/bash_completion$ mkdir bar
shawn.ygdrasil:~/work/bash_completion$ ls
bar/  foo/
shawn.ygdrasil:~/work/bash_completion$ export CDPATH=~/work/bash_completion
shawn.ygdrasil:~/work/bash_completion$ cd foo
/home/shawn/work/bash_completion/foo
shawn.ygdrasil:~/work/bash_completion/foo$ cd bar
/home/shawn/work/bash_completion/bar

OK, so far, so good.

shawn.ygdrasil:~/work/bash_completion/bar$ cd f

After typing in "cd f" and then you press TAB key, suddenly "f" becomes "foo/". Even when  there is no directory in the bar directory:

shawn.ygdrasil:~/work/bash_completion/bar$ cd foo/

Someone would say that this is nicer -- obviously ubuntu guys think so. But I absolutely do not think so. Since I don't want to get caught arguing which one is better, let's cut to the chase.

How to make bash's cool tab completion feature not to search matches in CDPATH?

Bash reads (at least with ubuntu distributions) /etc/profile when it is invoked. And the /etc/profile sources /etc/profile.d/*.sh. And there is this file: /etc/profile.d/bash_completion.sh. In this file, again sources /etc/bash_completion where there exists a function which searches for directory names when TAB key is typed in. The name of the function is "_cd()".

If you don't like bash completion to search for matches in CDPATH, you simply comment out some of the _cd() function in the /etc/bash_completion like:

# This meta-cd function observes the CDPATH variable, so that cd additionally
# completes on directories under those specified in CDPATH.
#
_cd()
{
    local cur IFS=$'\n' i j k
    _get_comp_words_by_ref cur

    # try to allow variable completion
    if [[ "$cur" == ?(\\)\$* ]]; then
        COMPREPLY=( $( compgen -v -P '$' -- "${cur#?(\\)$}" ) )
        return 0
    fi

    _compopt_o_filenames

    # Use standard dir completion if no CDPATH or parameter starts with /,
    # ./ or ../
    if [[ -z "${CDPATH:-}" || "$cur" == ?(.)?(.)/* ]]; then
        _filedir -d
        return 0
    fi

    local -r mark_dirs=$(_rl_enabled mark-directories && echo y)
    local -r mark_symdirs=$(_rl_enabled mark-symlinked-directories && echo y)

    # we have a CDPATH, so loop on its contents
    # for i in ${CDPATH//:/$'\n'}; do
    #     # create an array of matched subdirs
    #     k="${#COMPREPLY[@]}"
    #     for j in $( compgen -d $i/$cur ); do
    #         if [[ ( $mark_symdirs && -h $j || $mark_dirs && ! -h $j ) && ! -d ${j#$i/} ]]; then
    #             j="${j}/"
    #         fi
    #         COMPREPLY[k++]=${j#$i/}
    #     done
    # done

    _filedir -d

    if [[ ${#COMPREPLY[@]} -eq 1 ]]; then
        i=${COMPREPLY[0]}
        if [[ "$i" == "$cur" && $i != "*/" ]]; then
            COMPREPLY[0]="${i}/"
        fi
    fi

    return 0
}

Has the pain in the ass gone?

Good luck.

First check if your ssh_config file has following entries in it:

    GSSAPIAuthentication no
    GSSAPIDelegateCredentials no

If GSSAPIAuthentication is set to yes, try to change it to no.

If it does not work, refer to openssh FAQ:

http://www.openssh.com/faq.html#3.3

In most cases, it will be resolved by adding 'UseDNS no' entry to your sshd_config of the server you want to connect to. Note that the file name is sshd_config, not ssh_config.

Since XQuartz version 2.6.1, as I recall, XQuartz started to execute xterm if it is executed from dock or is launched automatically when you log on to the system (by your setup). It is quite like a pain in your butt if you made XQuartz run when you log on to your OS X. Here's how to keep XQuartz from running xterm when it is starting up: type following command in your terminal:

defaults write org.macosforge.xquartz.X11 app_to_run /usr/bin/true

More about this subject, refer to this page: http://xquartz.macosforge.org/trac/wiki/X11-UsersFAQ

P.S. Actually, older versions of XQuartz also did the same thing -- ran xterm when being started up by specific user action, e.g. clicking on the XQuartz icon on the dock or run a command like 'open XQuartz' or adding XQuartz to your logon items. It was just easy to tell XQuartz to stop launching xterm. You did not even need to run defaults command.

gdb> set stop-on-solib-event 1

이라고 해 주면, 디버깅 당하는 프로그램이 dlopen()을 호출할 때마다 실행을 멈춰 준다.

dlopen()으로 dynamic load를 하는 프로그램이 사용하는 library를 디버깅 해야 할 때 유용하다.

tkdiff is an essential tool for developers who are using Revision Control System.

It is such a shame thing that tkdiff does not support diff for mercurial.

I googled for tkdiff for mercurial and found this url:

http://mirror.leaseweb.com/gentoo-portage/dev-util/tkdiff/files/tkdiff-4.1.4-hg.patch

But it's been generated with -u option of diff. You need to create directories and blablabla.

Here goes diff file for tkdiff 4.1.4:

tkdiff.diff

You can check the version of tkdiff you're using by viewing its source. No need to be afraid of. tkdiff is just a script. It is all text file.

Just apply the patch by:

$ sudo patch -p0 /usr/bin/tkdiff < tkdiff.patch

Substitute "/usr/bin/tkdiff" with your path to tkdiff.

Enjoy it.

개인적으로 (회사 일 아님) Mercurial 을 사용할 일이 생겼다.

조금 써 보니 여태껏 subversion 을 사용하면서 가렵던 부분들이 시원하게 해결되어 있어서 아주 기뻤다.

1. 한번에 여러개의 버그를 수정하는 패치를 동시에 진행할 경우

subversion 을 사용할 때에는 버그 갯수만큼 checkout 받아서 각각 수정하고 진행하였지만, mercurial 은 그럴 필요 없다. Mercurial Queue 를 사용하면 아주 간단하고도 깔끔하게 원하는 패치만 올렸다가 내렸다가 할 수 있다.

2. 여러개의 호스트, 운영체제에서 동일한 패치를 적용해서 테스트 한 후, 실제의 repository 에 적용해야 하는 경우

subversion 을 사용할 때는 branch 를 생성해서 작업하지 않는 이상, 일일이 diff 파일을 각각의 호스트에 옮겨서 patch 해야만 했다. 정말 귀찮은 작업이었다.

mercurial 을 사용하면 전혀 그럴 필요가 없다. 각각의 호스트가 곧 repository 이기 때문에 그냥 변경 사항을 pull 하기만 하면 된다.

3. 하나의 버그 패치가 여러 단계로 이루어질 수 밖에 없어서 중간중간의 소스를 형상관리도구에 기억시켜야 하는 경우

subversion 을 사용하면 branch 를 따서 작업할 수 밖에 없는데, 버그 하나 때문에 branch 를 생성하는 것은 repository 를 번잡하게 만들기 때문에 그다지 내키지 않는다. 그렇지만, 단계별 작업을 어딘가에 저장하지 않고 working directory 에만 두자니, 첫번째 단계를 무사히 완료하고, 두번째 단계를 작업하다가, 두번째 단계만 재 작업해야 할 경우 아주 곤란하고... 이와같은 고민이 전혀 필요없다.

할 수 만 있다면, 지금 회사에서 사용하는 subversion 도 mercurial 로 옮기자고 이야기하고 싶다. 전 회사에도 mercurial 을 추천해 주고 싶다.

----

2011년 4월 23일 추가:

mercurial book 에서 저자는 mercurial 을 사용하다 보면 대부분의 작업이 "사회적" 작업이 될 것이라고 했는데, 조금 사용해 보니, 정말로 그러하다. mercurial 을 한번 사용해 보고 싶은 사람이라면 반드시 읽어 보기를 권한다:

Quick Start Guide: http://mercurial.selenic.com/quickstart/
Mercurial Book: http://mercurial.selenic.com/wiki/MercurialBook/