From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3668 invoked by alias); 25 Aug 2004 13:58:28 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 3616 invoked from network); 25 Aug 2004 13:58:22 -0000 Received: from unknown (HELO pegasus.siol.net) (193.189.160.40) by sourceware.org with SMTP; 25 Aug 2004 13:58:22 -0000 Received: from kudu.siol.net ([10.10.10.22]) by pegasus.siol.net (InterMail vK.4.03.05.03 201-232-132-103 license 1cbf71897a39210db31154c99f0b4628) with ESMTP id <20040825135821.HZUZ4845.pegasus@kudu.siol.net>; Wed, 25 Aug 2004 15:58:21 +0200 Received: from [192.168.0.77] ([193.77.157.20]) by kudu.siol.net (InterMail vK.4.03.05.03 201-232-132-103 license 1cbf71897a39210db31154c99f0b4628) with ESMTP id <20040825135821.CBMA16288.kudu@[193.77.157.20]>; Wed, 25 Aug 2004 15:58:21 +0200 Message-ID: <412C9AFC.70608@iskramedical.si> Date: Wed, 25 Aug 2004 13:58:00 -0000 From: Hinko Kocevar User-Agent: Mozilla Thunderbird 0.7 (X11/20040615) MIME-Version: 1.0 To: Kris Warkentin CC: gdb@sources.redhat.com Subject: Re: remote debugging and source files References: <412B4B05.8060705@iskramedical.si> <412B5FE6.8080406@iskramedical.si> <412B6515.2030501@iskramedical.si> <412B6ABC.9060804@qnx.com> <412B7E21.2080500@iskramedical.si> <412B82CB.4000503@qnx.com> In-Reply-To: <412B82CB.4000503@qnx.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2004-08/txt/msg00369.txt.bz2 Kris Warkentin wrote: > Hmm...according to your info shared, you have the loader here: > > 0x40001460 0x40011914 No > /opt/arm-linux/gcc-3.3.3-glibc-2.3.2/arm-softfloat-linux-gnu/lib/ld-linux.so.2 > > > so the breakpoint doesn't seem entirely unreasonable. Is there any > possibility that you have a different ld-linux.so.2 on the host and > target? It is same version on the host and on the target - glibc-2.3.2., but the one on target is cross compiled for ARM architecture, though. Is there any other kind of difference we are interested here? If debugging host application debugger stops on dynamic library load as expected and 'info shared' says (gdb) info sharedlibrary From To Syms Read Shared Object Library 0x40034680 0x400aadb4 Yes /usr/X11R6/lib/libX11.so.6 0x40134b40 0x4022f7b4 Yes /lib/i686/libc.so.6 0x40252eb0 0x40253de4 Yes /lib/libdl.so.2 0x40000c00 0x400139ef Yes /lib/ld-linux.so.2 > Then gdb would be calculating the breakpoint incorrectly based > on the host loader. If you take a look at /usr/include/link.h, you'll > find the r_debug structure. The comments in there will help you > calculate the breakpoint by hand (look at the r_brk element) and then > you can compare it to what gdb is coming up with. > Sounds easy, but to me, it is not - at all :). OK, here goes... I did 'maintenance info breakpoints' while debugging native app: ... -16 shlib events keep y 0x4000dd60 <_dl_debug_state_internal> breakpoint already hit 3 times ... So debugger stoped on shared library event 3 times (three dynamic libs were loaded) at <_dl_debug_state_internal> symbol found in ld-2.3.2.so. Using objdump I got the same offset, 0x0000dd60, for _dl_debug_state_internal. On ARM target using the same technique, shlib events are at 0x4000b8d8 while arm-linux-objdump says that _dl_debug_state_internal is at offset 0x0000c258. After setting breakpoint to 0x0000c258 debugger stopped 7 times (according to comments around r_debug that is OK) before my app was stated. Offset 0x0000b8d8 is location in _dl_signal_error. So how do I convince gdb to use correct address for shlib event? regards, h -- hinko kocevar iskramedical si Hinko Kocevar, developer Iskra Medical d.o.o., Stegne 23, 1k LJ, SLO-EU "Aì rén" | [Analects XII:22]