Re: [Crash-utility] Kernel Crash Analysis on Android
by Shankar, AmarX
Hi Dave,
Thanks for your info regarding kexec tool.
I am unable to download kexec from below link.
http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-too...
It says HTTP 404 Page Not Found.
Could you please guide me on this?
Thanks & Regards,
Amar Shankar
> On Wed, Mar 21, 2012 at 06:00:00PM +0000, Shankar, AmarX wrote:
>
> > I want to do kernel crash Analysis on Android Merrifield Target.
> >
> > Could someone please help me how to do it?
>
> Merrifield is pretty much similar than Medfield, e.g it has x86 core. So I
> guess you can follow the instructions how to setup kdump on x86 (see
> Documentation/kdump/kdump.txt) unless you already have that configured.
>
> crash should support this directly presuming you have vmlinux/vmcore files to
> feed it. You can configure crash to support x86 on x86_64 host by running:
>
> % make target=X86
> & make
>
> (or something along those lines).
Right -- just the first make command will suffice, i.e., when running
on an x86_64 host:
$ wget http://people.redhat.com/anderson/crash-6.0.4.tar.gz
$ tar xzf crash-6.0.4.tar.gz
...
$ cd crash-6.0.4
$ make target=X86
...
$ ./crash <path-to>/vmlinux <path-to>/vmcore
Dave
From: Shankar, AmarX
Sent: Wednesday, March 21, 2012 11:30 PM
To: 'crash-utility(a)redhat.com'
Subject: Kernel Crash Analysis on Android
Hi,
I want to do kernel crash Analysis on Android Merrifield Target.
Could someone please help me how to do it?
Thanks & Regards,
Amar Shankar
1 year, 1 month
[PATCH] kmem, snap: iomem/ioport display and vmcore snapshot support
by HATAYAMA Daisuke
Some days ago I was in a situation that I had to convert vmcore in
kvmdump format into ELF since some extension module we have locally
can be used only on relatively old crash utility, around version 4,
but such old crash utility cannot handle kvmdump format.
To do the conversion in handy, I used snap command with some modifications
so that it tries to use iomem information in vmcore instead of host's
/proc/iomem. This patch is its cleaned-up version.
In this development, I naturally got down to also making an interface
for an access to resource objects, and so together with the snap
command's patch, I also extended kmem command for iomem/ioport
support. Actually:
kmem -r displays /proc/iomem
crash> kmem -r
00000000-0000ffff : reserved
00010000-0009dbff : System RAM
0009dc00-0009ffff : reserved
000c0000-000c7fff : Video ROM
...
and kmem -R displays /proc/ioport
crash> kmem -R
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
...
Looking into old version of kernel source code back, resource structure
has been unchanged since linux-2.4.0. I borrowed the way of walking on
resouce tree in this patch from the lastest v3.3-rc series, but I
guess the logic is also applicable to old kernels. I expect Dave's
regression testsuite.
Also, there would be another command more sutable for iomem/ioport.
If necessay, I'll repost the patch.
---
HATAYAMA Daisuke (4):
Add vmcore snapshot support
Add kmem -r and -R options
Add dump iomem/ioport functions; a helper for resource objects
Add a helper function for iterating resource objects
defs.h | 9 ++++
extensions/snap.c | 54 ++++++++++++++++++++++-
help.c | 2 +
memory.c | 122 +++++++++++++++++++++++++++++++++++++++++++++++++++--
4 files changed, 180 insertions(+), 7 deletions(-)
--
Thanks.
HATAYAMA Daisuke
1 year, 1 month
Re: [Crash-utility] question about phys_base
by Dave Anderson
----- Original Message -----
> >
> > OK, so then I don't understand what you mean by "may be the same"?
> >
> > You didn't answer my original question, but if I understand you correctly,
> > it would be impossible for the qemu host to create a PT_LOAD segment that
> > describes an x86_64 guest's __START_KERNEL_map region, because the host
> > doesn't know that what kind of kernel the guest is running.
>
> Yes. Even if the guest is linux, it is still impossible to do it. Because
> the guest maybe in the second kernel.
>
> qemu-dump walks all guest's page table and collect virtual address and
> physical address mapping. If the page is not used by guest, the virtual is set
> to 0. I create PT_LOAD according to such mapping. So if the guest is linux,
> there may be a PT_LOAD segment that describes __START_KERNEL_map region.
> But the information stored in PT_LOAD maybe for the second kernel. If crash
> uses it, crash will see the second kernel, not the first kernel.
Just to be clear -- what do you mean by the "second" kernel? Do you
mean that a guest kernel crashed guest, and did a kdump operation,
and that second kdump kernel failed somehow, and now you're trying
to do a "virsh dump" on the kdump kernel?
Dave
1 year, 1 month
question about phys_base
by Wen Congyang
Hi, Dave
I am implementing a new dump command in the qemu. The vmcore's
format is elf(like kdump). And I try to provide phys_base in
the PT_LOAD. But if the os uses the first vcpu do kdump, the
value of phys_base is wrong.
I find a function x86_64_virt_phys_base() in crash's code.
Is it OK to call this function first? If the function
successes, we do not calculate phys_base according to PT_LOAD.
Thanks
Wen Congyang
1 year, 1 month
[PATCH] runq: search current task's runqueue explicitly
by HATAYAMA Daisuke
Currently, runq sub-command doesn't consider CFS runqueue's current
task removed from CFS runqueue. Due to this, the remaining CFS
runqueus that follow the current task's is not displayed. This patch
fixes this by making runq sub-command search current task's runqueue
explicitly.
Note that CFS runqueue exists for each task group, and so does CFS
runqueue's current task, and the above search needs to be done
recursively.
Test
====
On vmcore I made 7 task groups:
root group --- A --- AA --- AAA
+ +- AAB
|
+- AB --- ABA
+- ABB
and then I ran three CPU bound tasks, which is exactly the same as
int main(void) { for (;;) continue; return 0; }
for each task group, including root group; so total 24 tasks. For
readability, I annotated each task name with its belonging group name.
For example, loop.ABA belongs to task group ABA.
Look at CPU0 collumn below. [before] lacks 8 tasks and [after]
successfully shows all tasks on the runqueue, which is identical to
the result of [sched debug] that is expected to ouput correct result.
I'll send this vmcore later.
[before]
crash> runq | cat
CPU 0 RUNQUEUE: ffff88000a215f80
CURRENT: PID: 28263 TASK: ffff880037aaa040 COMMAND: "loop.ABA"
RT PRIO_ARRAY: ffff88000a216098
[no tasks queued]
CFS RB_ROOT: ffff88000a216010
[120] PID: 28262 TASK: ffff880037cc40c0 COMMAND: "loop.ABA"
<cut>
[after]
crash_fix> runq
CPU 0 RUNQUEUE: ffff88000a215f80
CURRENT: PID: 28263 TASK: ffff880037aaa040 COMMAND: "loop.ABA"
RT PRIO_ARRAY: ffff88000a216098
[no tasks queued]
CFS RB_ROOT: ffff88000a216010
[120] PID: 28262 TASK: ffff880037cc40c0 COMMAND: "loop.ABA"
[120] PID: 28271 TASK: ffff8800787a8b40 COMMAND: "loop.ABB"
[120] PID: 28272 TASK: ffff880037afd580 COMMAND: "loop.ABB"
[120] PID: 28245 TASK: ffff8800785e8b00 COMMAND: "loop.AB"
[120] PID: 28246 TASK: ffff880078628ac0 COMMAND: "loop.AB"
[120] PID: 28241 TASK: ffff880078616b40 COMMAND: "loop.AA"
[120] PID: 28239 TASK: ffff8800785774c0 COMMAND: "loop.AA"
[120] PID: 28240 TASK: ffff880078617580 COMMAND: "loop.AA"
[120] PID: 28232 TASK: ffff880079b5d4c0 COMMAND: "loop.A"
<cut>
[sched debug]
crash> runq -d
CPU 0
[120] PID: 28232 TASK: ffff880079b5d4c0 COMMAND: "loop.A"
[120] PID: 28239 TASK: ffff8800785774c0 COMMAND: "loop.AA"
[120] PID: 28240 TASK: ffff880078617580 COMMAND: "loop.AA"
[120] PID: 28241 TASK: ffff880078616b40 COMMAND: "loop.AA"
[120] PID: 28245 TASK: ffff8800785e8b00 COMMAND: "loop.AB"
[120] PID: 28246 TASK: ffff880078628ac0 COMMAND: "loop.AB"
[120] PID: 28262 TASK: ffff880037cc40c0 COMMAND: "loop.ABA"
[120] PID: 28263 TASK: ffff880037aaa040 COMMAND: "loop.ABA"
[120] PID: 28271 TASK: ffff8800787a8b40 COMMAND: "loop.ABB"
[120] PID: 28272 TASK: ffff880037afd580 COMMAND: "loop.ABB"
<cut>
Diff stat
=========
defs.h | 1 +
task.c | 37 +++++++++++++++++--------------------
2 files changed, 18 insertions(+), 20 deletions(-)
Thanks.
HATAYAMA, Daisuke
1 year, 1 month
[RFC] makedumpfile, crash: LZO compression support
by HATAYAMA Daisuke
Hello,
This is a RFC patch set that adds LZO compression support to
makedumpfile and crash utility. LZO is as good as in size but by far
better in speed than ZLIB, leading to reducing down time during
generation of crash dump and refiltering.
How to build:
1. Get LZO library, which is provided as lzo-devel package on recent
linux distributions, and is also available on author's website:
http://www.oberhumer.com/opensource/lzo/.
2. Apply the patch set to makedumpfile v1.4.0 and crash v6.0.0.
3. Build both using make. But for crash, do the following now:
$ make CFLAGS="-llzo2"
How to use:
I've newly used -l option for lzo compression in this patch. So for
example, do as follows:
$ makedumpfile -l vmcore dumpfile
$ crash vmlinux dumpfile
Request of configure-like feature for crash utility:
I would like configure-like feature on crash utility for users to
select wheather to add LZO feature actually or not in build-time,
that is: ./configure --enable-lzo or ./configure --disable-lzo.
The reason is that support staff often downloads and installs the
latest version of crash utility on machines where lzo library is not
provided.
Looking at the source code, it looks to me that crash does some kind
of configuration processing in a local manner, around configure.c,
and I guess it's difficult to use autoconf tools directly.
Or is there another better way?
Performance Comparison:
Sample Data
Ideally, I must have measured the performance for many enough
vmcores generated from machines that was actually running, but now
I don't have enough sample vmcores, I couldn't do so. So this
comparison doesn't answer question on I/O time improvement. This
is TODO for now.
Instead, I choosed worst and best cases regarding compression
ratio and speed only. Specifically, the former is /dev/urandom and
the latter is /dev/zero.
I get the sample data of 10MB, 100MB and 1GB by doing like this:
$ dd bs=4096 count=$((1024*1024*1024/4096)) if=/dev/urandom of=urandom.1GB
How to measure
Then I performed compression for each block, 4096 bytes, and
measured total compression time and output size. See attached
mycompress.c.
Result
See attached file result.txt.
Discussion
For both kinds of data, lzo's compression was considerably quicker
than zlib's. Compression ratio is about 37% for urandom data, and
about 8.5% for zero data. Actual situation of physical memory
would be in between the two cases, and so I guess average
compression time ratio is between 37% and 8.5%.
Although beyond the topic of this patch set, we can estimate worst
compression time on more data size since compression is performed
block size wise and the compression time increases
linearly. Estimated worst time on 2TB memory is about 15 hours for
lzo and about 40 hours for zlib. In this case, compressed data
size is larger than the original, so they are really not used,
compression time is fully meaningless. I think compression must be
done in parallel, and I'll post such patch later.
Diffstat
* makedumpfile
diskdump_mod.h | 3 +-
makedumpfile.c | 98 +++++++++++++++++++++++++++++++++++++++++++++++++------
makedumpfile.h | 12 +++++++
3 files changed, 101 insertions(+), 12 deletions(-)
* crash
defs.h | 1 +
diskdump.c | 20 +++++++++++++++++++-
diskdump.h | 3 ++-
3 files changed, 22 insertions(+), 2 deletions(-)
TODO
* evaluation including I/O time using actual vmcores
Thanks.
HATAYAMA, Daisuke
1 year, 1 month
Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
by tachibana＠mxm.nes.nec.co.jp
Hi Hatayama-san,
On 2011/06/29 12:12:18 +0900, HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> wrote:
> From: Dave Anderson <anderson(a)redhat.com>
> Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
> Date: Tue, 28 Jun 2011 08:57:42 -0400 (EDT)
>
> >
> >
> > ----- Original Message -----
> >> Fujitsu has stand-alone dump mechanism based on firmware level
> >> functionality, which we call SADUMP, in short.
> >>
> >> We've maintained utility tools internally but now we're thinking that
> >> the best is crash utility and makedumpfile supports the sadump format
> >> for the viewpoint of both portability and maintainability.
> >>
> >> We'll be of course responsible for its maintainance in a continuous
> >> manner. The sadump dump format is very similar to diskdump format and
> >> so kdump (compressed) format, so we estimate patch set would be a
> >> relatively small size.
> >>
> >> Could you tell me whether crash utility and makedumpfile can support
> >> the sadump format? If OK, we'll start to make patchset.
I think it's not bad to support sadump by makedumpfile. However I have
several questions.
- Do you want to use makedumpfile to make an existing file that sadump has
dumped small?
- It isn't possible to support the same form as kdump-compressed format
now, is it?
- When the information that makedumpfile reads from a note of /proc/vmcore
(or a header of kdump-compressed format) is added by an extension of
makedumpfile, do you need to modify sadump?
Thanks
tachibana
> >
> > Sure, yes, the crash utility can always support another dumpfile format.
> >
>
> Thanks. It helps a lot.
>
> > It's unclear to me how similar SADUMP is to diskdump/compressed-kdump.
> > Does your internal version patch diskdump.c, or do you maintain your
> > own "sadump.c"? I ask because if your patchset is at all intrusive,
> > I'd prefer it be kept in its own file, primarily for maintainability,
> > but also because SADUMP is essentially a black-box to anybody outside
> > Fujitsu.
>
> What I meant when I used ``similar'' is both literally and
> logically. The format consists of diskdump header-like header, two
> kinds of bitmaps used for the same purpose as those in diskump format,
> and memory data. They can be handled in common with the existing data
> structure, diskdump_data, non-intrusively, so I hope they are placed
> in diskdump.c.
>
> On the other hand, there's a code to be placed at such specific
> area. sadump is triggered depending on kdump's progress and so
> register values to be contained in vmcore varies according to the
> progress: If crash_notes has been initialized when sadump is
> triggered, sadump packs the register values in crash_notes; if not
> yet, packs registers gathered by firmware. This is sadump specific
> processing, so I think putting it in specific sadump.c file is a
> natural and reasonable choise.
>
> Anyway, I have not made any patch set for this. I'll post a patch set
> when I complete.
>
> Again, thanks a lot for the positive answer.
>
> Thanks.
> HATAYAMA, Daisuke
>
>
> _______________________________________________
> kexec mailing list
> kexec(a)lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
1 year, 1 month
[PATCH] Allows to change the error output direction
by Daniel Kwon
Currently, the error() is always printing the output to the console
through 'stdout'. This does not follow redirection which is good when
you want to know error while redirecting commands output to a file.
However, there are situations that you want to hide error messages or
redirect it into somewhere else.
Using 'set stderr' command, it can be changed to three different
destination - fixed 'stdout', following redirection (fp), or a custom
file path.
crash> set stderr
stderr: stdout
crash> sym 0x523 > /dev/null
sym: invalid address: 0x523
crash> set stderr fp
stderr: fp
crash> sym 0x523 > /dev/null
crash> set stderr /tmp/err.log
stderr: /tmp/err.log
crash> sym 0x523 > /dev/null
crash> set stderr stdout
stderr: stdout
crash> sym 0x523 > /dev/null
sym: invalid address: 0x523
---
defs.h | 2 ++
help.c | 5 +++++
main.c | 2 ++
tools.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++---
4 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/defs.h b/defs.h
index ccffe58..57850c6 100644
--- a/defs.h
+++ b/defs.h
@@ -553,6 +553,8 @@ struct program_context {
ulong scope; /* optional text context address */
ulong nr_hash_queues; /* hash queue head count */
char *(*read_vmcoreinfo)(const char *);
+ FILE *stderr; /* error() message direction */
+ char stderr_path[PATH_MAX]; /* stderr path information */
};
#define READMEM pc->readmem
diff --git a/help.c b/help.c
index 581e616..ddc8e86 100644
--- a/help.c
+++ b/help.c
@@ -1093,6 +1093,10 @@ char *help_set[] = {
" redzone on | off if on, CONFIG_SLUB object addresses
displayed by",
" the kmem command will point to the
SLAB_RED_ZONE",
" padding inserted at the beginning of
the object.",
+" stderr stdout | fp | <path> set the direction of error put.
'stdout' always",
+" print on console. 'fp' follows the
redirection",
+" or pipe command. '<path>' can be any
file path",
+" in the filesystem which can save the output",
" ",
" Internal variables may be set in four manners:\n",
" 1. entering the set command in $HOME/.%src.",
@@ -1144,6 +1148,7 @@ char *help_set[] = {
" scope: (not set)",
" offline: show",
" redzone: on",
+" stderr: stdout",
" ",
" Show the current context:\n",
" %s> set",
diff --git a/main.c b/main.c
index 83ccd31..68bdec4 100644
--- a/main.c
+++ b/main.c
@@ -1085,6 +1085,8 @@ setup_environment(int argc, char **argv)
* to pipes or output files.
*/
fp = stdout;
+ pc->stderr = stdout;
+ strcpy(pc->stderr_path, "stdout");
/*
* Start populating the program_context structure. It's used so
diff --git a/tools.c b/tools.c
index 2d95c3a..840d07c 100644
--- a/tools.c
+++ b/tools.c
@@ -58,6 +58,9 @@ __error(int type, char *fmt, ...)
void *retaddr[NUMBER_STACKFRAMES] = { 0 };
va_list ap;
+ if (!strcmp(pc->stderr_path, "fp"))
+ pc->stderr = fp;
+
if (CRASHDEBUG(1) || (pc->flags & DROP_CORE)) {
SAVE_RETURN_ADDRESS(retaddr);
console("error() trace: %lx => %lx => %lx => %lx\n",
@@ -69,7 +72,7 @@ __error(int type, char *fmt, ...)
va_end(ap);
if (!fmt && FATAL_ERROR(type)) {
- fprintf(stdout, "\n");
+ fprintf(pc->stderr, "\n");
clean_exit(1);
}
@@ -95,14 +98,14 @@ __error(int type, char *fmt, ...)
buf);
fflush(pc->stdpipe);
} else {
- fprintf(stdout, "%s%s%s %s%s",
+ fprintf(pc->stderr, "%s%s%s %s%s",
new_line || end_of_line ? "\n" : "",
type == WARNING ? "WARNING" :
type == NOTE ? "NOTE" :
type == CONT ? spacebuf : pc->curcmd,
type == CONT ? " " : ":",
buf, end_of_line ? "\n" : "");
- fflush(stdout);
+ fflush(pc->stderr);
}
if ((fp != stdout) && (fp != pc->stdpipe) && (fp != pc->tmpfile)) {
@@ -2483,6 +2486,51 @@ cmd_set(void)
}
return;
+ } else if (STREQ(args[optind], "stderr")) {
+ if (args[optind+1]) {
+ FILE *tmp_fp = NULL;
+ char tmp_path[PATH_MAX];
+
+ optind++;
+ if (STREQ(args[optind], "stdout")) {
+ tmp_fp = stdout;
+ strcpy(tmp_path, "stdout");
+ } else if (STREQ(args[optind], "fp")) {
+ tmp_fp = fp;
+ strcpy(tmp_path, "fp");
+ } else {
+ if (strlen(args[optind]) >= PATH_MAX) {
+ error(INFO, "path
length %d is too long. (max=%d)\n",
+
strlen(args[optind]), PATH_MAX);
+ return;
+ }
+ tmp_fp = fopen(args[optind], "a");
+ if (tmp_fp != NULL) {
+ strcpy(tmp_path, args[optind]);
+ } else {
+ error(INFO, "invalid
path: %s\n",
+ args[optind]);
+ return;
+ }
+
+ }
+
+ if (strcmp(pc->stderr_path, tmp_path)) {
+ if (strcmp(pc->stderr_path, "stdout")
+ && strcmp(pc->stderr_path, "fp")) {
+ fclose(pc->stderr);
+ }
+ pc->stderr = tmp_fp;
+ strcpy(pc->stderr_path, tmp_path);
+ }
+ }
+
+ if (runtime) {
+ fprintf(fp, "stderr: %s\n",
+ pc->stderr_path);
+ }
+ return;
+
} else if (XEN_HYPER_MODE()) {
error(FATAL, "invalid argument for the Xen hypervisor\n");
} else if (pc->flags & MINIMAL_MODE) {
@@ -2590,6 +2638,7 @@ show_options(void)
fprintf(fp, "(not set)\n");
fprintf(fp, " offline: %s\n", pc->flags2 & OFFLINE_HIDE ?
"hide" : "show");
fprintf(fp, " redzone: %s\n", pc->flags2 & REDZONE ? "on" : "off");
+ fprintf(fp, " stderr: %s\n", pc->stderr_path);
}
--
1.8.3.1
5 years, 5 months
[PATCH v2] crash: dis: introduce count in reverse and forward mode
by Aaron Tomlin
Changes since v1:
- Update 'dis' help page
- Resolve patch fuzz
The purpose of this patch is to add support for a count value in reverse
or forward mode, during disassembly:
'dis [-r|-f] [symbol|address] [count]'
For example:
crash> dis -f list_del+0x16 4
0xffffffff812b3346 <list_del+22>: jne 0xffffffff812b3381 <list_del+81>
0xffffffff812b3348 <list_del+24>: mov (%rbx),%rax
0xffffffff812b334b <list_del+27>: mov 0x8(%rax),%r8
0xffffffff812b334f <list_del+31>: cmp %r8,%rbx
crash> dis -r list_del+0x16 4
0xffffffff812b333c <list_del+12>: mov 0x8(%rdi),%rax
0xffffffff812b3340 <list_del+16>: mov (%rax),%r8
0xffffffff812b3343 <list_del+19>: cmp %r8,%rdi
0xffffffff812b3346 <list_del+22>: jne 0xffffffff812b3381 <list_del+81>
To support this feature, I have essentially incorported GDB commit
bb556f1facb ("Add negative repeat count to 'x' command"), with some
additional changes to maintain default behaviour i.e. always display the
target instruction with the examine command.
Signed-off-by: Aaron Tomlin <atomlin(a)redhat.com>
---
gdb-7.6.patch | 331 ++++++++++++++++++++++++++++++++++++++++++++++++++
help.c | 4 +-
kernel.c | 33 ++---
3 files changed, 351 insertions(+), 17 deletions(-)
diff --git a/gdb-7.6.patch b/gdb-7.6.patch
index cd75dcf..96cdef4 100644
--- a/gdb-7.6.patch
+++ b/gdb-7.6.patch
@@ -2447,3 +2447,334 @@ diff -up gdb-7.6/opcodes/configure.orig gdb-7.6/opcodes/configure
#else
# error "!__i386__ && !__x86_64__"
#endif
+--- gdb-7.6/gdb/printcmd.c.orig
++++ gdb-7.6/gdb/printcmd.c
+@@ -201,8 +201,13 @@ decode_format (char **string_ptr, int oformat, int osize)
+ val.count = 1;
+ val.raw = 0;
+
++ if (*p == '-')
++ {
++ val.count = -1;
++ p++;
++ }
+ if (*p >= '0' && *p <= '9')
+- val.count = atoi (p);
++ val.count *= atoi (p);
+ while (*p >= '0' && *p <= '9')
+ p++;
+
+@@ -795,6 +800,232 @@ print_address_demangle (const struct value_print_options *opts,
+ }
+
+
++/* Find the address of the instruction that is INST_COUNT instructions before
++ the instruction at ADDR.
++ Since some architectures have variable-length instructions, we can't just
++ simply subtract INST_COUNT * INSN_LEN from ADDR. Instead, we use line
++ number information to locate the nearest known instruction boundary,
++ and disassemble forward from there. If we go out of the symbol range
++ during disassembling, we return the lowest address we've got so far and
++ set the number of instructions read to INST_READ. */
++
++static CORE_ADDR
++find_instruction_backward (struct gdbarch *gdbarch, CORE_ADDR addr,
++ int inst_count, int *inst_read)
++{
++ /* The vector PCS is used to store instruction addresses within
++ a pc range. */
++ CORE_ADDR loop_start, loop_end, p, func_addr;
++ VEC (CORE_ADDR) *pcs = NULL;
++ struct symtab_and_line sal;
++ struct cleanup *cleanup = make_cleanup (VEC_cleanup (CORE_ADDR), &pcs);
++ int actual_count = 0;
++
++ *inst_read = 0;
++ inst_count--;
++ loop_start = loop_end = addr;
++
++ find_pc_partial_function (addr, NULL, &func_addr, NULL);
++ for (p = func_addr; p != addr;)
++ {
++ p += gdb_insn_length (gdbarch, p);
++ actual_count++;
++ }
++ if (inst_count > actual_count)
++ inst_count = actual_count;
++
++ /* In each iteration of the outer loop, we get a pc range that ends before
++ LOOP_START, then we count and store every instruction address of the range
++ iterated in the loop.
++ If the number of instructions counted reaches INST_COUNT, return the
++ stored address that is located INST_COUNT instructions back from ADDR.
++ If INST_COUNT is not reached, we subtract the number of counted
++ instructions from INST_COUNT, and go to the next iteration. */
++ do
++ {
++ VEC_truncate (CORE_ADDR, pcs, 0);
++ sal = find_pc_sect_line (loop_start, NULL, 1);
++ if (sal.line <= 0)
++ {
++ /* We reach here when line info is not available. In this case,
++ we print a message and just exit the loop. The return value
++ is calculated after the loop. */
++ printf_filtered (_("No line number information available "
++ "for address "));
++ wrap_here (" ");
++ print_address (gdbarch, loop_start - 1, gdb_stdout);
++ printf_filtered ("\n");
++ break;
++ }
++
++ loop_end = loop_start;
++ loop_start = sal.pc;
++
++ /* This loop pushes instruction addresses in the range from
++ LOOP_START to LOOP_END. */
++ for (p = loop_start; p < loop_end;)
++ {
++ VEC_safe_push (CORE_ADDR, pcs, p);
++ p += gdb_insn_length (gdbarch, p);
++ }
++
++ inst_count -= VEC_length (CORE_ADDR, pcs);
++ *inst_read += VEC_length (CORE_ADDR, pcs);
++ }
++ while (inst_count > 0);
++
++ /* After the loop, the vector PCS has instruction addresses of the last
++ source line we processed, and INST_COUNT has a negative value.
++ We return the address at the index of -INST_COUNT in the vector for
++ the reason below.
++ Let's assume the following instruction addresses and run 'x/-4i 0x400e'.
++ Line X of File
++ 0x4000
++ 0x4001
++ 0x4005
++ Line Y of File
++ 0x4009
++ 0x400c
++ => 0x400e
++ 0x4011
++ find_instruction_backward is called with INST_COUNT = 4 and expected to
++ return 0x4001. When we reach here, INST_COUNT is set to -1 because
++ it was subtracted by 2 (from Line Y) and 3 (from Line X). The value
++ 4001 is located at the index 1 of the last iterated line (= Line X),
++ which is simply calculated by -INST_COUNT.
++ The case when the length of PCS is 0 means that we reached an area for
++ which line info is not available. In such case, we return LOOP_START,
++ which was the lowest instruction address that had line info. */
++ p = VEC_length (CORE_ADDR, pcs) > 0
++ ? VEC_index (CORE_ADDR, pcs, -inst_count)
++ : loop_start;
++
++ /* INST_READ includes all instruction addresses in a pc range. Need to
++ exclude the beginning part up to the address we're returning. That
++ is, exclude {0x4000} in the example above. */
++ if (inst_count < 0)
++ *inst_read += inst_count;
++
++ do_cleanups (cleanup);
++ return p;
++}
++
++/* Backward read LEN bytes of target memory from address MEMADDR + LEN,
++ placing the results in GDB's memory from MYADDR + LEN. Returns
++ a count of the bytes actually read. */
++
++static int
++read_memory_backward (struct gdbarch *gdbarch,
++ CORE_ADDR memaddr, gdb_byte *myaddr, int len)
++{
++ int errcode;
++ int nread; /* Number of bytes actually read. */
++
++ /* First try a complete read. */
++ errcode = target_read_memory (memaddr, myaddr, len);
++ if (errcode == 0)
++ {
++ /* Got it all. */
++ nread = len;
++ }
++ else
++ {
++ /* Loop, reading one byte at a time until we get as much as we can. */
++ memaddr += len;
++ myaddr += len;
++ for (nread = 0; nread < len; ++nread)
++ {
++ errcode = target_read_memory (--memaddr, --myaddr, 1);
++ if (errcode != 0)
++ {
++ /* The read was unsuccessful, so exit the loop. */
++ printf_filtered (_("Cannot access memory at address %s\n"),
++ paddress (gdbarch, memaddr));
++ break;
++ }
++ }
++ }
++ return nread;
++}
++
++/* Returns true if X (which is LEN bytes wide) is the number zero. */
++
++static int
++integer_is_zero (const gdb_byte *x, int len)
++{
++ int i = 0;
++
++ while (i < len && x[i] == 0)
++ ++i;
++ return (i == len);
++}
++
++/* Find the start address of a string in which ADDR is included.
++ Basically we search for '\0' and return the next address,
++ but if OPTIONS->PRINT_MAX is smaller than the length of a string,
++ we stop searching and return the address to print characters as many as
++ PRINT_MAX from the string. */
++
++static CORE_ADDR
++find_string_backward (struct gdbarch *gdbarch,
++ CORE_ADDR addr, int count, int char_size,
++ const struct value_print_options *options,
++ int *strings_counted)
++{
++ const int chunk_size = 0x20;
++ gdb_byte *buffer = NULL;
++ struct cleanup *cleanup = NULL;
++ int read_error = 0;
++ int chars_read = 0;
++ int chars_to_read = chunk_size;
++ int chars_counted = 0;
++ int count_original = count;
++ CORE_ADDR string_start_addr = addr;
++
++ gdb_assert (char_size == 1 || char_size == 2 || char_size == 4);
++ buffer = (gdb_byte *) xmalloc (chars_to_read * char_size);
++ cleanup = make_cleanup (xfree, buffer);
++ while (count > 0 && read_error == 0)
++ {
++ int i;
++
++ addr -= chars_to_read * char_size;
++ chars_read = read_memory_backward (gdbarch, addr, buffer,
++ chars_to_read * char_size);
++ chars_read /= char_size;
++ read_error = (chars_read == chars_to_read) ? 0 : 1;
++ /* Searching for '\0' from the end of buffer in backward direction. */
++ for (i = 0; i < chars_read && count > 0 ; ++i, ++chars_counted)
++ {
++ int offset = (chars_to_read - i - 1) * char_size;
++
++ if (integer_is_zero (buffer + offset, char_size)
++ || chars_counted == options->print_max)
++ {
++ /* Found '\0' or reached print_max. As OFFSET is the offset to
++ '\0', we add CHAR_SIZE to return the start address of
++ a string. */
++ --count;
++ string_start_addr = addr + offset + char_size;
++ chars_counted = 0;
++ }
++ }
++ }
++
++ /* Update STRINGS_COUNTED with the actual number of loaded strings. */
++ *strings_counted = count_original - count;
++
++ if (read_error != 0)
++ {
++ /* In error case, STRING_START_ADDR is pointing to the string that
++ was last successfully loaded. Rewind the partially loaded string. */
++ string_start_addr -= chars_counted * char_size;
++ }
++
++ do_cleanups (cleanup);
++ return string_start_addr;
++}
++
+ /* Examine data at address ADDR in format FMT.
+ Fetch it from memory and print on gdb_stdout. */
+
+@@ -808,12 +1039,16 @@ do_examine (struct format_data fmt, struct gdbarch *gdbarch, CORE_ADDR addr)
+ int i;
+ int maxelts;
+ struct value_print_options opts;
++ int need_to_update_next_address = 0;
++ CORE_ADDR addr_rewound = 0;
++ int is_backward;
+
+ format = fmt.format;
+ size = fmt.size;
+ count = fmt.count;
+ next_gdbarch = gdbarch;
+ next_address = addr;
++ is_backward = count < 0;
+
+ /* Instruction format implies fetch single bytes
+ regardless of the specified size.
+@@ -878,9 +1113,43 @@ do_examine (struct format_data fmt, struct gdbarch *gdbarch, CORE_ADDR addr)
+
+ get_formatted_print_options (&opts, format);
+
++ if (is_backward)
++ {
++ /* This is the negative repeat count case.
++ We rewind the address based on the given repeat count and format,
++ then examine memory from there in forward direction. */
++
++ count = -count;
++ if (format == 'i')
++ {
++ next_address = find_instruction_backward (gdbarch, addr, count,
++ &count);
++ }
++ else if (format == 's')
++ {
++ next_address = find_string_backward (gdbarch, addr, count,
++ TYPE_LENGTH (val_type),
++ &opts, &count);
++ }
++ else
++ {
++ next_address = addr - count * TYPE_LENGTH (val_type);
++ }
++
++ /* The following call to print_formatted updates next_address in every
++ iteration. In backward case, we store the start address here
++ and update next_address with it before exiting the function. */
++ addr_rewound = (format == 's'
++ ? next_address - TYPE_LENGTH (val_type)
++ : next_address);
++ need_to_update_next_address = 1;
++ }
++
+ /* Print as many objects as specified in COUNT, at most maxelts per line,
+ with the address of the next one at the start of each line. */
+
++ if (is_backward)
++ count++;
+ while (count > 0)
+ {
+ QUIT;
+@@ -923,6 +1192,9 @@ do_examine (struct format_data fmt, struct gdbarch *gdbarch, CORE_ADDR addr)
+ printf_filtered ("\n");
+ gdb_flush (gdb_stdout);
+ }
++
++ if (need_to_update_next_address)
++ next_address = addr_rewound;
+ }
+
+ static void
+@@ -2535,7 +2807,8 @@ Format letters are o(octal), x(hex), d(decimal), u(unsigned decimal),\n\
+ t(binary), f(float), a(address), i(instruction), c(char) and s(string).\n\
+ Size letters are b(byte), h(halfword), w(word), g(giant, 8 bytes).\n\
+ The specified number of objects of the specified size are printed\n\
+-according to the format.\n\n\
++according to the format. If a negative number is specified, memory is\n\
++examined backward from the address.\n\n\
+ Defaults for format and size letters are those previously used.\n\
+ Default count is 1. Default address is following last thing printed\n\
+ with this command or \"print\"."));
diff --git a/help.c b/help.c
index 581e616..4d028e1 100644
--- a/help.c
+++ b/help.c
@@ -7278,8 +7278,8 @@ char *help_dis[] = {
" count the number of instructions to be disassembled (default is 1).",
" If no count argument is entered, and the starting address",
" is entered as a text symbol, then the whole routine will be",
-" disassembled. The count argument is ignored when used with",
-" the -r option.",
+" disassembled. The count argument is supported when used with",
+" the -r and -f option.",
"\nEXAMPLES",
" Disassemble the sys_signal() routine without, and then with, line numbers:\n",
" %s> dis sys_signal",
diff --git a/kernel.c b/kernel.c
index f01dc2e..e1f0b7e 100644
--- a/kernel.c
+++ b/kernel.c
@@ -1931,16 +1931,10 @@ cmd_dis(void)
}
if (args[++optind]) {
- if (reverse || forward) {
- error(INFO,
- "count argument ignored with -%s option\n",
- reverse ? "r" : "f");
- } else {
- req->count = stol(args[optind],
+ req->count = stol(args[optind],
FAULT_ON_ERROR, NULL);
- req->flags &= ~GNU_FUNCTION_ONLY;
- count_entered++;
- }
+ req->flags &= ~GNU_FUNCTION_ONLY;
+ count_entered++;
}
if (sources) {
@@ -1992,6 +1986,10 @@ cmd_dis(void)
}
}
+ if (reverse || forward)
+ if (count_entered && req->count == 1)
+ reverse = forward = 0;
+
if (reverse || forward) {
target = req->addr;
if ((sp = value_search(target, NULL)) == NULL)
@@ -2006,14 +2004,19 @@ cmd_dis(void)
do_machdep_filter = machdep->dis_filter(req->addr, NULL, radix);
open_tmpfile();
- if (reverse)
- sprintf(buf5, "x/%ldi 0x%lx",
- (target - req->addr) ? target - req->addr : 1,
- req->addr);
- else
+ if (reverse || forward) {
+ if (count_entered && req->count)
+ sprintf(buf5, "x/%s%ldi 0x%lx", reverse ? "-" : "",
+ req->count, target);
+ else
+ sprintf(buf5, "x/%ldi 0x%lx",
+ forward ? req->addr2 - req->addr :
+ (target - req->addr) ? target - req->addr : 1,
+ forward ? target : req->addr);
+ } else
sprintf(buf5, "x/%ldi 0x%lx",
count_entered && req->count ? req->count :
- forward || req->flags & GNU_FUNCTION_ONLY ?
+ req->flags & GNU_FUNCTION_ONLY ?
req->addr2 - req->addr : 1,
req->addr);
gdb_pass_through(buf5, NULL, GNU_RETURN_ON_ERROR);
--
2.20.1
5 years, 5 months
