* Tracing code memcpy()-ied to a new location
@ 2011-05-03 15:47 Paolo Pisati
2011-05-03 16:01 ` Paolo Pisati
0 siblings, 1 reply; 3+ messages in thread
From: Paolo Pisati @ 2011-05-03 15:47 UTC (permalink / raw)
To: gdb
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 <relocate_new_kernel>: 0xe59f0074 0xe59f106c
0xe3500000 0x0a000014
0xc0056c5c <relocate_new_kernel+16>: 0xe4903004 0xe3130001
0x0a000001 0xe3c34001
0xc0056c6c <relocate_new_kernel+32>: 0xeafffffa 0xe3130002
0x0a000001 0xe3c30002
0xc0056c7c <relocate_new_kernel+48>: 0xeafffff6 0xe3130004
0x0a000000 0xea000008
0xc0056c8c <relocate_new_kernel+64>: 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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Tracing code memcpy()-ied to a new location
2011-05-03 15:47 Tracing code memcpy()-ied to a new location Paolo Pisati
@ 2011-05-03 16:01 ` Paolo Pisati
2011-05-04 12:55 ` Jan Kratochvil
0 siblings, 1 reply; 3+ messages in thread
From: Paolo Pisati @ 2011-05-03 16:01 UTC (permalink / raw)
To: gdb
[resending due to bad formatting...]
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 <relocate_new_kernel>: 0xe59f0074
0xe59f106c 0xe3500000 0x0a000014
0xc0056c5c <relocate_new_kernel+16>: 0xe4903004 0xe3130001
0x0a000001 0xe3c34001
0xc0056c6c <relocate_new_kernel+32>: 0xeafffffa
0xe3130002 0x0a000001 0xe3c30002
0xc0056c7c <relocate_new_kernel+48>: 0xeafffff6
0xe3130004 0x0a000000 0xea000008
0xc0056c8c <relocate_new_kernel+64>: 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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Tracing code memcpy()-ied to a new location
2011-05-03 16:01 ` Paolo Pisati
@ 2011-05-04 12:55 ` Jan Kratochvil
0 siblings, 0 replies; 3+ messages in thread
From: Jan Kratochvil @ 2011-05-04 12:55 UTC (permalink / raw)
To: Paolo Pisati; +Cc: gdb
On Tue, 03 May 2011 18:01:19 +0200, Paolo Pisati wrote:
> 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?
(gdb) help add-symbol-file
Load symbols from FILE, assuming FILE has been dynamically loaded.
Usage: add-symbol-file FILE ADDR [-s <SECT> <SECT_ADDR> -s <SECT> <SECT_ADDR> ...]
ADDR is the starting address of the file's text.
The optional arguments are section-name section-address pairs and
should be specified if the data and bss segments are not contiguous
with the text. SECT is a section name to be loaded at SECT_ADDR.
So ADDR is not the starting address (reboot_code_buffer) but you must also add
to it the VMA of the .text section of FILE (see `readelf -WS FILE').
Regards,
Jan
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-05-04 12:55 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-03 15:47 Tracing code memcpy()-ied to a new location Paolo Pisati
2011-05-03 16:01 ` Paolo Pisati
2011-05-04 12:55 ` Jan Kratochvil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).