This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [PATCH] Make the dcache (code/stack cache) handle line reading errors better.
- From: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Wed, 21 May 2014 06:51:04 +0000
- Subject: RE: [PATCH] Make the dcache (code/stack cache) handle line reading errors better.
- Authentication-results: sourceware.org; auth=none
- References: <1396601586-24380-1-git-send-email-markus dot t dot metzger at intel dot com> <53760BDF dot 2080500 at redhat dot com> <A78C989F6D9628469189715575E55B230C16E478 at IRSMSX104 dot ger dot corp dot intel dot com> <A78C989F6D9628469189715575E55B230C16E5C6 at IRSMSX104 dot ger dot corp dot intel dot com> <537A7A80 dot 3050801 at redhat dot com> <A78C989F6D9628469189715575E55B230C16EE8F at IRSMSX104 dot ger dot corp dot intel dot com> <537B389C dot 4080901 at redhat dot com> <A78C989F6D9628469189715575E55B230C16EFE7 at IRSMSX104 dot ger dot corp dot intel dot com> <537B8DA6 dot 4080601 at redhat dot com>
> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Pedro Alves
> Sent: Tuesday, May 20, 2014 7:15 PM
> 8<---------------
> From: Pedro Alves <palves@redhat.com>
> Date: Tue, 20 May 2014 12:26:01 +0100
> Subject: [PATCH] Make the dcache (code/stack cache) handle line reading
> errors
> better.
>
> The dcache (code/stack cache) is supposed to be transparent, but it's
> actually not in one case. dcache tries to read chunks (cache lines)
> at a time off of the target. This may end up trying to read
> unaccessible or unavailable memory. Currently the caller an xfer error
'gets' is missing.
> in this case. But if the specific bits of memory the caller actually
> wanted are available and accessible, then the caller should get the
> memory it wanted, not an error.
> + Copyright 2012-2014 Free Software Foundation, Inc.
Why 2012-?
> +void *first_mapped_page;
> +void *first_unmapped_page;
> +void *last_mapped_page;
> +void *last_unmapped_page;
The _unmapped_page variants seem not to be used.
> + /* Disassembling 0s should behave on all targets. */
> + memset (p, 0, pg_count * pg_size);
Shouldn't be necessary. The pages are supposed to be zero-initialized.
> +# Test that dcache behaves correctly when reading a cache line fails.
> +
> +standard_testfile
> +
> +if { [prepare_for_testing "failed to prepare" ${testfile}] } {
And I always thought you had to supply $srcfile, as well. Can
prepare_for_testing derive the source name from the executable name
and some path magic?
> +proc disassemble { what } {
> + global hex gdb_prompt
> +
> + set cmd "disassemble $what"
> + gdb_test_multiple $cmd $cmd {
> + -re "Cannot access memory.*$gdb_prompt $" {
> + fail $cmd
> + }
> + -re "End of assembler dump\.\r\n$gdb_prompt $" {
> + pass $cmd
> + }
Wouldn't simply checking for "End of assembler dump\.\r\n" suffice?
Wouldn't it even be more robust as it would catch all kinds of errors?
Regards,
Markus.
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052