From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2488 invoked by alias); 3 May 2011 15:47:20 -0000 Received: (qmail 2476 invoked by uid 22791); 3 May 2011 15:47:18 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SARE_BAYES_5x8,SARE_BAYES_6x8,SARE_BAYES_7x8,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 May 2011 15:47:04 +0000 Received: by wwb17 with SMTP id 17so199394wwb.12 for ; Tue, 03 May 2011 08:47:03 -0700 (PDT) Received: by 10.227.206.66 with SMTP id ft2mr774023wbb.94.1304437622891; Tue, 03 May 2011 08:47:02 -0700 (PDT) Received: from [192.168.0.32] (dynamic-adsl-94-36-146-130.clienti.tiscali.it [94.36.146.130]) by mx.google.com with ESMTPS id w25sm132132wbd.56.2011.05.03.08.47.01 (version=SSLv3 cipher=OTHER); Tue, 03 May 2011 08:47:02 -0700 (PDT) Message-ID: <4DC02372.6040409@gmail.com> Date: Tue, 03 May 2011 15:47:00 -0000 From: Paolo Pisati User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Tracing code memcpy()-ied to a new location Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-05/txt/msg00021.txt.bz2 Dear, while debugging linux's kexec() on an arm board, i hit this problem in machine_kexec(): http://fxr.watson.org/fxr/source/arch/arm/kernel/machine_kexec.c?v=linux-2.6 68 /* copy our kernel relocation code to the control code page */ 69 memcpy(reboot_code_buffer, 70 relocate_new_kernel, relocate_new_kernel_size); here we copy the relocate_new_kernel routine (arch/arm/kernel/relocate_kernel.S::relocate_new_kernel()) to reboot_code_buffer, and later... 83 cpu_reset(reboot_code_buffer_phys); we jump to it tracing it with gdb i have this: 132 cpu_reset(reboot_code_buffer_phys); (gdb) x/20 relocate_new_kernel <- the original routine 0xc0056c4c : 0xe59f0074 0xe59f106c 0xe3500000 0x0a000014 0xc0056c5c : 0xe4903004 0xe3130001 0x0a000001 0xe3c34001 0xc0056c6c : 0xeafffffa 0xe3130002 0x0a000001 0xe3c30002 0xc0056c7c : 0xeafffff6 0xe3130004 0x0a000000 0xea000008 0xc0056c8c : 0xe3130008 0x0afffff1 0xe3c33008 0xe3a06b01 (gdb) x/20 reboot_code_buffer <- the same routine as the VM/MMU sees it 0xef356000: 0xe59f0074 0xe59f106c 0xe3500000 0x0a000014 0xef356010: 0xe4903004 0xe3130001 0x0a000001 0xe3c34001 0xef356020: 0xeafffffa 0xe3130002 0x0a000001 0xe3c30002 0xef356030: 0xeafffff6 0xe3130004 0x0a000000 0xea000008 0xef356040: 0xe3130008 0x0afffff1 0xe3c33008 0xe3a06b01 (gdb) p/x reboot_code_buffer_phys $1 = 0xaf356000 (gdb) mon mdw phys 0xaf356000 20 <- again the same routine in physical memory/location 0xaf356000: e59f0074 e59f106c e3500000 0a000014 e4903004 e3130001 0a000001 e3c34001 0xaf356020: eafffffa e3130002 0a000001 e3c30002 eafffff6 e3130004 0a000000 ea000008 0xaf356040: e3130008 0afffff1 e3c33008 e3a06b01 this confirms that the memory in reboot_code_buffer/reboot_code_buffer_phys contains relocate_new_kernel() (gdb) stepi 0xc0056b3c 132 cpu_reset(reboot_code_buffer_phys); (gdb) stepi cpu_v7_reset () at /home/flag/canonical/ubuntu-natty/arch/arm/mm/proc-v7.S:64 64 mov pc, r0 (gdb) stepi 0xaf356000 in ?? () and from this point on, i can't follow the code anymore. So here is the question: since i know there is relocate_new_kernel() in that location, is there a way to tell gdb to "remap" the symbols/environment/$whatever of that routine in that location so i can keep debugging it? -- bye, p.