From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20414 invoked by alias); 14 Nov 2005 22:28:53 -0000 Received: (qmail 20400 invoked by uid 22791); 14 Nov 2005 22:28:49 -0000 Received: from wproxy.gmail.com (HELO wproxy.gmail.com) (64.233.184.202) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 14 Nov 2005 22:28:49 +0000 Received: by wproxy.gmail.com with SMTP id 58so1319681wri for ; Mon, 14 Nov 2005 14:28:47 -0800 (PST) Received: by 10.64.10.8 with SMTP id 8mr6367195qbj; Mon, 14 Nov 2005 14:28:47 -0800 (PST) Received: by 10.65.20.19 with HTTP; Mon, 14 Nov 2005 14:28:47 -0800 (PST) Message-ID: <7f45d9390511141428q190485f5l@mail.gmail.com> Date: Mon, 14 Nov 2005 22:28:00 -0000 From: Shaun Jackman Reply-To: Shaun Jackman To: gdb@sources.redhat.com Subject: Simulating arm-linux binaries MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00273.txt.bz2 Hello, I'm adding support to sim/arm (arm-elf-run) to run statically linked Linux binaries. The work is going well so far; I'm already able to run a "Hello, world!" application linked against uClibc. Running a "Hello, world!" application linked against glibc is proving to be a little more difficult. If anyone else is interested in this work, and perhaps in helping with this work, I'll send my current patch your way. I'll be sending a patch upstream that works with uClibc shortly. It irks me, though, that glibc isn't yet working. Particularly annoying is that arm-elf-run and arm-elf-gdb 'target sim' are giving different results. When I call arm-elf-run hello, glibc calls the syscalls { uname, brk, brk mmap) and then dies shortly after the simulated mmap fails (errno =3D ENOMEM) with unhandled instructions at address 0x504 and 0x50c. When I run the same binary with arm-elf-gdb, glibc calls the syscalls { uname, geteuid32, getuid32, getegid32, getgid32, writev } and the writev call displays... *** glibc detected *** corrupted double-linked list: 0xff00006d *** These two invocations of the same binary seem to be going down very different code paths within glibc. Any idea why that is? Is gdb calling the ARMulator differently somehow than sim? Cheers, Shaun