* [PATCH] testsuite/gdb.dwarf2: Fix for dw2-dos-drive failure on ARM [not found] <CANW4E-3h4UODqrXEjP2Z8AmZa+eYtXnTY337EosXTSE6016uGQ@mail.gmail.com> @ 2013-07-15 10:27 ` Omair Javaid 2013-07-30 15:38 ` Pedro Alves 0 siblings, 1 reply; 11+ messages in thread From: Omair Javaid @ 2013-07-15 10:27 UTC (permalink / raw) To: gdb-patches A test-case in gdb.dwarf2/dw2-dos-drive.exp fails on ARM. Problem occurs due to an unaligned access of text section. This patch correctly aligns text section to 4 bytes. This patch has been tested on armv7 and x86_64. gdb/testsuite/ChangeLog: 2013-07-15 Omair Javaid <Omair.Javaid@linaro.org> * gdb.dwarf2/dw2-dos-drive.S: Corrected text section alignment =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S,v retrieving revision 1.1 diff -u -p -r1.1 dw2-dos-drive.S --- gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S 17 Jan 2013 20:40:44 -0000 1.1 +++ gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S 19 Jun 2013 19:43:32 -0000 @@ -15,7 +15,7 @@ .text pc_start: - .byte 0 + .4byte 0 pc_end: .section .debug_info ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-dos-drive failure on ARM 2013-07-15 10:27 ` [PATCH] testsuite/gdb.dwarf2: Fix for dw2-dos-drive failure on ARM Omair Javaid @ 2013-07-30 15:38 ` Pedro Alves 2013-09-19 15:23 ` Omair Javaid 0 siblings, 1 reply; 11+ messages in thread From: Pedro Alves @ 2013-07-30 15:38 UTC (permalink / raw) To: Omair Javaid; +Cc: gdb-patches On 07/15/2013 11:26 AM, Omair Javaid wrote: > A test-case in gdb.dwarf2/dw2-dos-drive.exp fails on ARM. Problem occurs > due to an unaligned access of text section. This patch correctly aligns > text section to 4 bytes. This patch has been tested on armv7 and x86_64. #1 - What exactly is unaligned? You're reserving 4 bytes instead of 1 for pc_start. Does that really influence alignment of text ? It doesn't for me, with an arm-linux toolchain: $ arm-linux-gcc dw2-dos-drive.S -o a.out -c $ arm-gp2x-linux-objdump -h a.out ... Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000001 00000000 00000000 00000034 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE ... vs ... Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000004 00000000 00000000 00000034 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE ... IOW, size increases, but alignment stays the same. #2 - Where's the actual access/fault? AFAICS, the test doesn't even execute the compiled object's code. #3 - How come these other tests aren't likewise affected? $ grep "\.byte 0$" * -B 4 dw2-canonicalize-type.S- along with this program. If not, see <http://www.gnu.org/licenses/>. */ dw2-canonicalize-type.S- dw2-canonicalize-type.S- .text dw2-canonicalize-type.S- .globl main dw2-canonicalize-type.S:main: .byte 0 -- pr11465.S- .text pr11465.S-text_start: pr11465.S-_ZN1N1cE: pr11465.S- /* Valid function must have non-empty PC range. */ pr11465.S: .byte 0 > > gdb/testsuite/ChangeLog: > > 2013-07-15 Omair Javaid <Omair.Javaid@linaro.org> > > * gdb.dwarf2/dw2-dos-drive.S: Corrected text section alignment Missing period at end of sentence. That's a "why". You should say a "what" instead: * gdb.dwarf2/dw2-dos-drive.S (pc_start): Use .4byte instead of .byte. > > =================================================================== > RCS file: /cvs/src/src/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S,v > retrieving revision 1.1 > diff -u -p -r1.1 dw2-dos-drive.S > --- gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S 17 Jan 2013 20:40:44 > -0000 1.1 > +++ gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S 19 Jun 2013 19:43:32 -0000 > @@ -15,7 +15,7 @@ > > .text > pc_start: > - .byte 0 > + .4byte 0 > pc_end: > > .section .debug_info > -- Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-dos-drive failure on ARM 2013-07-30 15:38 ` Pedro Alves @ 2013-09-19 15:23 ` Omair Javaid 2013-09-19 15:53 ` Pedro Alves 0 siblings, 1 reply; 11+ messages in thread From: Omair Javaid @ 2013-09-19 15:23 UTC (permalink / raw) To: Pedro Alves; +Cc: gdb-patches Thanks everyone for the feedback. I am getting following problem with 1byte text section in the dw2-dos-drive.exp (gdb) PASS: gdb.dwarf2/dw2-dos-drive.exp: set breakpoint pending off break 'z:file.c':func Cannot access memory at address 0x0 When I change this to 4bytes the problem gets fixed. That is why I thought this could be an unaligned illegal memory access but I accept that the above comments verify that its not a alignment issue. Can anyone help me figure out what could be the cause of this problem? Thanks! -- Omair. On 30 July 2013 16:38, Pedro Alves <palves@redhat.com> wrote: > On 07/15/2013 11:26 AM, Omair Javaid wrote: >> A test-case in gdb.dwarf2/dw2-dos-drive.exp fails on ARM. Problem occurs >> due to an unaligned access of text section. This patch correctly aligns >> text section to 4 bytes. This patch has been tested on armv7 and x86_64. > > #1 - What exactly is unaligned? You're reserving 4 bytes instead > of 1 for pc_start. Does that really influence alignment of text ? > It doesn't for me, with an arm-linux toolchain: > > $ arm-linux-gcc dw2-dos-drive.S -o a.out -c > $ arm-gp2x-linux-objdump -h a.out > ... > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 00000001 00000000 00000000 00000034 2**0 > CONTENTS, ALLOC, LOAD, READONLY, CODE > ... > > vs > > ... > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 00000004 00000000 00000000 00000034 2**0 > CONTENTS, ALLOC, LOAD, READONLY, CODE > ... > > IOW, size increases, but alignment stays the same. > > #2 - Where's the actual access/fault? AFAICS, the test doesn't > even execute the compiled object's code. > > #3 - How come these other tests aren't likewise affected? > > $ grep "\.byte 0$" * -B 4 > dw2-canonicalize-type.S- along with this program. If not, see <http://www.gnu.org/licenses/>. */ > dw2-canonicalize-type.S- > dw2-canonicalize-type.S- .text > dw2-canonicalize-type.S- .globl main > dw2-canonicalize-type.S:main: .byte 0 > -- > pr11465.S- .text > pr11465.S-text_start: > pr11465.S-_ZN1N1cE: > pr11465.S- /* Valid function must have non-empty PC range. */ > pr11465.S: .byte 0 > >> >> gdb/testsuite/ChangeLog: >> >> 2013-07-15 Omair Javaid <Omair.Javaid@linaro.org> >> >> * gdb.dwarf2/dw2-dos-drive.S: Corrected text section alignment > > Missing period at end of sentence. That's a "why". You should say > a "what" instead: > > * gdb.dwarf2/dw2-dos-drive.S (pc_start): Use .4byte instead of > .byte. > >> >> =================================================================== >> RCS file: /cvs/src/src/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S,v >> retrieving revision 1.1 >> diff -u -p -r1.1 dw2-dos-drive.S >> --- gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S 17 Jan 2013 20:40:44 >> -0000 1.1 >> +++ gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S 19 Jun 2013 19:43:32 -0000 >> @@ -15,7 +15,7 @@ >> >> .text >> pc_start: >> - .byte 0 >> + .4byte 0 >> pc_end: >> >> .section .debug_info >> > > -- > Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-dos-drive failure on ARM 2013-09-19 15:23 ` Omair Javaid @ 2013-09-19 15:53 ` Pedro Alves 2013-10-01 8:32 ` Omair Javaid 0 siblings, 1 reply; 11+ messages in thread From: Pedro Alves @ 2013-09-19 15:53 UTC (permalink / raw) To: Omair Javaid; +Cc: gdb-patches Please don't top post. On 09/19/2013 04:23 PM, Omair Javaid wrote: > Thanks everyone for the feedback. > > I am getting following problem with 1byte text section in the dw2-dos-drive.exp > > (gdb) PASS: gdb.dwarf2/dw2-dos-drive.exp: set breakpoint pending off > break 'z:file.c':func > Cannot access memory at address 0x0 > > When I change this to 4bytes the problem gets fixed. That is why I > thought this could be an unaligned illegal memory access but I accept > that the above comments verify that its not a alignment issue. > > Can anyone help me figure out what could be the cause of this problem? Breakpoint instructions on ARM are 4-byte wide. It sounds like GDB is trying to read the memory at the breakpoint's address, and that fails (that error message comes from GDB, not the program). AFAICS, the test doesn't execute the compiled object's code, so GDB will try to read memory from the binary's sections. As the section is only 1 byte long, and probably no other section is allocated contiguously, that'll fail... To confirm, debug GDB under GDB, and put a break on throw_it or some such. Then work up the stack to see where that is thrown, and why. -- Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-dos-drive failure on ARM 2013-09-19 15:53 ` Pedro Alves @ 2013-10-01 8:32 ` Omair Javaid 2013-10-01 15:34 ` Pedro Alves 0 siblings, 1 reply; 11+ messages in thread From: Omair Javaid @ 2013-10-01 8:32 UTC (permalink / raw) To: Pedro Alves; +Cc: gdb-patches On 19 September 2013 20:53, Pedro Alves <palves@redhat.com> wrote: > Please don't top post. > > On 09/19/2013 04:23 PM, Omair Javaid wrote: >> Thanks everyone for the feedback. >> >> I am getting following problem with 1byte text section in the dw2-dos-drive.exp >> >> (gdb) PASS: gdb.dwarf2/dw2-dos-drive.exp: set breakpoint pending off >> break 'z:file.c':func >> Cannot access memory at address 0x0 >> >> When I change this to 4bytes the problem gets fixed. That is why I >> thought this could be an unaligned illegal memory access but I accept >> that the above comments verify that its not a alignment issue. >> >> Can anyone help me figure out what could be the cause of this problem? > > Breakpoint instructions on ARM are 4-byte wide. It sounds like > GDB is trying to read the memory at the breakpoint's address, and > that fails (that error message comes from GDB, not the program). > AFAICS, the test doesn't execute the compiled object's code, so > GDB will try to read memory from the binary's sections. As the > section is only 1 byte long, and probably no other section is allocated > contiguously, that'll fail... To confirm, debug GDB under GDB, > and put a break on throw_it or some such. Then work up the stack > to see where that is thrown, and why. > > -- > Pedro Alves > I have verified the error is being thrown by gdb while its unable to read the 4byte breakpoint address. Heres the call stack: Thread [1] (Suspended: Breakpoint hit.) 38 throw_error() exceptions.c:444 0x0016728c 37 memory_error() corefile.c:204 0x001d1fcc 36 read_memory() corefile.c:223 0x001d201a 35 read_memory_unsigned_integer() corefile.c:312 0x001d2166 34 arm_skip_prologue() arm-tdep.c:1452 0x00054270 33 gdbarch_skip_prologue() gdbarch.c:2603 0x00176e5c 32 skip_prologue_sal() symtab.c:2869 0x0013dad2 31 find_function_start_sal() symtab.c:2782 0x0013d9aa 30 symbol_to_sal() linespec.c:3622 0x0014f722 29 convert_linespec_to_sals() linespec.c:2028 0x0014d6fa 28 parse_linespec() linespec.c:2319 0x0014dc04 27 decode_line_full() linespec.c:2430 0x0014df44 26 parse_breakpoint_sals() breakpoint.c:9323 0x00108560 25 create_sals_from_address_default() breakpoint.c:14306 0x0010ec6e 24 bkpt_create_sals_from_address() breakpoint.c:13123 0x0010d736 23 create_breakpoint() breakpoint.c:9554 0x00108a6e 22 break_command_1() breakpoint.c:9772 0x00108ef0 21 break_command() breakpoint.c:9845 0x00109000 20 do_cfunc() cli-decode.c:113 0x000a4782 19 cmd_func() cli-decode.c:1859 0x000a669c 18 execute_command() top.c:484 0x0022299c 17 command_handler() event-top.c:431 0x0016fcac 16 command_line_handler() event-top.c:629 0x0017028e 15 rl_callback_read_char() callback.c:220 0x0026a9d2 14 rl_callback_read_char_wrapper() event-top.c:163 0x0016f880 13 stdin_event_handler() event-top.c:371 0x0016fba6 12 handle_file_event() event-loop.c:768 0x0016ec66 11 process_event() event-loop.c:342 0x0016e288 10 gdb_do_one_event() event-loop.c:406 0x0016e348 9 start_event_loop() event-loop.c:431 0x0016e38a 8 cli_command_loop() event-top.c:176 0x0016f8b2 7 current_interp_command_loop() interps.c:331 0x001685d8 6 captured_command_loop() main.c:258 0x00168e1c 5 catch_errors() exceptions.c:546 0x00167458 4 captured_main() main.c:1041 0x0016a19a 3 catch_errors() exceptions.c:546 0x00167458 2 gdb_main() main.c:1050 0x0016a1ca 1 main() gdb.c:34 0x0004f26c I guess only way to address it is to either use the patch I have posted or may be disable the test for arm? Any suggestions? Thanks! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-dos-drive failure on ARM 2013-10-01 8:32 ` Omair Javaid @ 2013-10-01 15:34 ` Pedro Alves 2013-12-02 21:17 ` Omair Javaid 0 siblings, 1 reply; 11+ messages in thread From: Pedro Alves @ 2013-10-01 15:34 UTC (permalink / raw) To: Omair Javaid; +Cc: gdb-patches On 10/01/2013 09:32 AM, Omair Javaid wrote: > On 19 September 2013 20:53, Pedro Alves <palves@redhat.com> wrote: >> Please don't top post. >> >> On 09/19/2013 04:23 PM, Omair Javaid wrote: >>> Thanks everyone for the feedback. >>> >>> I am getting following problem with 1byte text section in the dw2-dos-drive.exp >>> >>> (gdb) PASS: gdb.dwarf2/dw2-dos-drive.exp: set breakpoint pending off >>> break 'z:file.c':func >>> Cannot access memory at address 0x0 >>> >>> When I change this to 4bytes the problem gets fixed. That is why I >>> thought this could be an unaligned illegal memory access but I accept >>> that the above comments verify that its not a alignment issue. >>> >>> Can anyone help me figure out what could be the cause of this problem? >> >> Breakpoint instructions on ARM are 4-byte wide. It sounds like >> GDB is trying to read the memory at the breakpoint's address, and >> that fails (that error message comes from GDB, not the program). >> AFAICS, the test doesn't execute the compiled object's code, so >> GDB will try to read memory from the binary's sections. As the >> section is only 1 byte long, and probably no other section is allocated >> contiguously, that'll fail... To confirm, debug GDB under GDB, >> and put a break on throw_it or some such. Then work up the stack >> to see where that is thrown, and why. >> >> -- >> Pedro Alves >> > > I have verified the error is being thrown by gdb while its unable to > read the 4byte breakpoint address. > Heres the call stack: > Thread [1] (Suspended: Breakpoint hit.) > 38 throw_error() exceptions.c:444 0x0016728c > 37 memory_error() corefile.c:204 0x001d1fcc > 36 read_memory() corefile.c:223 0x001d201a > 35 read_memory_unsigned_integer() corefile.c:312 0x001d2166 > 34 arm_skip_prologue() arm-tdep.c:1452 0x00054270 Right, though this is actually parsing the prologue: static CORE_ADDR arm_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR pc) { ... for (skip_pc = pc; skip_pc < limit_pc; skip_pc += 4) { inst = read_memory_unsigned_integer (skip_pc, 4, byte_order_for_code); Some ports detect errors and instead return the PC as far as it was managed to be skip. E.g. rs6000-tdep.c:skip_prologue (rs6000==PowerPC): /* Fetch the instruction and convert it to an integer. */ if (target_read_memory (pc, buf, 4)) break; op = extract_unsigned_integer (buf, 4, byte_order); But not all do that. SPARC also doesn't throw. But others do throw an error like ARM. I tried SH and that throws error like ARM; MIPS and xtensa, from inspection, look like they'll throw but I haven't tried it. AAarch64 throws like ARM, but that's not surprising. Anyway, there's no standard. > 33 gdbarch_skip_prologue() gdbarch.c:2603 0x00176e5c > 32 skip_prologue_sal() symtab.c:2869 0x0013dad2 > 31 find_function_start_sal() symtab.c:2782 0x0013d9aa > 30 symbol_to_sal() linespec.c:3622 0x0014f722 > 29 convert_linespec_to_sals() linespec.c:2028 0x0014d6fa > 28 parse_linespec() linespec.c:2319 0x0014dc04 > 27 decode_line_full() linespec.c:2430 0x0014df44 > 26 parse_breakpoint_sals() breakpoint.c:9323 0x00108560 ... > I guess only way to address it is to either use the patch I have > posted or may be disable the test for arm? Any suggestions? Another other way to handle this would be to make the prologue scanner cope with this, and not error out, like some ports do. But it's not clear at all to me that's a useful behavior. Even if we pretended we found the end of the prologue in this case, the address we would find in this particular case would never be a valid address to put a breakpoint at (the function's first address). If we tried setting a breakpoint there, who knows what is it would be overwritten by the bytes that fall off the section (we can be 99.99% sure the next section would be aligned, and the gap wouldn't be used for anything, but still... So, I think it might be better to leave the scanner as is, throwing the error while it has context about it, and let the user (or higher-level code) decide what to do. Another way to tackle this could be to actually disable prologue skipping, by setting the breakpoint at exactly the func's first instruction, with the '*'/address operator: -gdb_test "break 'z:file.c':func" {Breakpoint [0-9]+ at .*} +gdb_test "break *'z:file.c'::func" {Breakpoint [0-9]+ at .*} This doesn't actually work, though I think that's a bug. I'll file a PR. But, even if it did, that converts a linespec to an expression, which may not be a universal solution, as tests with this issue might need to use a "real" linespec... So, in the end, it'd be fine with me to just go in the direction of your original patch then. But I think it deserves a comment: pc_start: /* Enough space to fit one instruction. */ - .byte 0 + .4byte 0 pc_end: Could you resend your patch, with that change, a fixed commit log description and fixed ChangeLog? Thanks, -- Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-dos-drive failure on ARM 2013-10-01 15:34 ` Pedro Alves @ 2013-12-02 21:17 ` Omair Javaid 2014-01-15 18:39 ` Omair Javaid 2014-01-16 10:25 ` Pedro Alves 0 siblings, 2 replies; 11+ messages in thread From: Omair Javaid @ 2013-12-02 21:17 UTC (permalink / raw) To: Pedro Alves; +Cc: gdb-patches, Patch Tracking On 10/01/2013 08:34 PM, Pedro Alves wrote: > On 10/01/2013 09:32 AM, Omair Javaid wrote: >> On 19 September 2013 20:53, Pedro Alves <palves@redhat.com> wrote: >>> Please don't top post. >>> >>> On 09/19/2013 04:23 PM, Omair Javaid wrote: >>>> Thanks everyone for the feedback. >>>> >>>> I am getting following problem with 1byte text section in the dw2-dos-drive.exp >>>> >>>> (gdb) PASS: gdb.dwarf2/dw2-dos-drive.exp: set breakpoint pending off >>>> break 'z:file.c':func >>>> Cannot access memory at address 0x0 >>>> >>>> When I change this to 4bytes the problem gets fixed. That is why I >>>> thought this could be an unaligned illegal memory access but I accept >>>> that the above comments verify that its not a alignment issue. >>>> >>>> Can anyone help me figure out what could be the cause of this problem? >>> >>> Breakpoint instructions on ARM are 4-byte wide. It sounds like >>> GDB is trying to read the memory at the breakpoint's address, and >>> that fails (that error message comes from GDB, not the program). >>> AFAICS, the test doesn't execute the compiled object's code, so >>> GDB will try to read memory from the binary's sections. As the >>> section is only 1 byte long, and probably no other section is allocated >>> contiguously, that'll fail... To confirm, debug GDB under GDB, >>> and put a break on throw_it or some such. Then work up the stack >>> to see where that is thrown, and why. >>> >>> -- >>> Pedro Alves >>> >> >> I have verified the error is being thrown by gdb while its unable to >> read the 4byte breakpoint address. >> Heres the call stack: >> Thread [1] (Suspended: Breakpoint hit.) >> 38 throw_error() exceptions.c:444 0x0016728c >> 37 memory_error() corefile.c:204 0x001d1fcc >> 36 read_memory() corefile.c:223 0x001d201a >> 35 read_memory_unsigned_integer() corefile.c:312 0x001d2166 >> 34 arm_skip_prologue() arm-tdep.c:1452 0x00054270 > > Right, though this is actually parsing the prologue: > > static CORE_ADDR > arm_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR pc) > { > ... > for (skip_pc = pc; skip_pc < limit_pc; skip_pc += 4) > { > inst = read_memory_unsigned_integer (skip_pc, 4, byte_order_for_code); > > Some ports detect errors and instead return the PC as far > as it was managed to be skip. > E.g. rs6000-tdep.c:skip_prologue (rs6000==PowerPC): > > /* Fetch the instruction and convert it to an integer. */ > if (target_read_memory (pc, buf, 4)) > break; > op = extract_unsigned_integer (buf, 4, byte_order); > > But not all do that. SPARC also doesn't throw. But others do throw > an error like ARM. I tried SH and that throws error like ARM; MIPS > and xtensa, from inspection, look like they'll throw but I haven't > tried it. AAarch64 throws like ARM, but that's not surprising. > Anyway, there's no standard. > >> 33 gdbarch_skip_prologue() gdbarch.c:2603 0x00176e5c >> 32 skip_prologue_sal() symtab.c:2869 0x0013dad2 >> 31 find_function_start_sal() symtab.c:2782 0x0013d9aa >> 30 symbol_to_sal() linespec.c:3622 0x0014f722 >> 29 convert_linespec_to_sals() linespec.c:2028 0x0014d6fa >> 28 parse_linespec() linespec.c:2319 0x0014dc04 >> 27 decode_line_full() linespec.c:2430 0x0014df44 >> 26 parse_breakpoint_sals() breakpoint.c:9323 0x00108560 > ... > >> I guess only way to address it is to either use the patch I have >> posted or may be disable the test for arm? Any suggestions? > > Another other way to handle this would be to make the prologue > scanner cope with this, and not error out, like some ports do. But > it's not clear at all to me that's a useful behavior. Even if we > pretended we found the end of the prologue in this case, the address > we would find in this particular case would never be a valid address > to put a breakpoint at (the function's first address). If we tried > setting a breakpoint there, who knows what is it would be overwritten > by the bytes that fall off the section (we can be 99.99% sure > the next section would be aligned, and the gap wouldn't be used > for anything, but still... So, I think it might be better to leave > the scanner as is, throwing the error while it has context about > it, and let the user (or higher-level code) decide what to do. > > Another way to tackle this could be to actually disable prologue > skipping, by setting the breakpoint at exactly the func's first > instruction, with the '*'/address operator: > > -gdb_test "break 'z:file.c':func" {Breakpoint [0-9]+ at .*} > +gdb_test "break *'z:file.c'::func" {Breakpoint [0-9]+ at .*} > > This doesn't actually work, though I think that's a bug. I'll > file a PR. > > But, even if it did, that converts a linespec to an expression, > which may not be a universal solution, as tests with this issue > might need to use a "real" linespec... > > So, in the end, it'd be fine with me to just go in the > direction of your original patch then. But I think it deserves > a comment: > > pc_start: > /* Enough space to fit one instruction. */ > - .byte 0 > + .4byte 0 > pc_end: > > Could you resend your patch, with that change, a fixed commit > log description and fixed ChangeLog? > > Thanks, > Sorry about responding late to this. I have attached the patch along with commit message and a ChangeLog. Commit Log Message: Avoid test failure due to error thrown from skip prologue code by an illegal memory access in case of single byte text section gdb/testsuite/ChangeLog: 2013-12-02 Omair Javaid <Omair.Javaid@linaro.org> * gdb.dwarf2/dw2-dos-drive.S: Changed text section size to 4 bytes --- gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S b/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S index 682ba4e..f226912 100644 --- a/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S +++ b/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S @@ -15,7 +15,7 @@ .text pc_start: - .byte 0 + .4byte 0 pc_end: .section .debug_info -- ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-dos-drive failure on ARM 2013-12-02 21:17 ` Omair Javaid @ 2014-01-15 18:39 ` Omair Javaid 2014-01-16 10:25 ` Pedro Alves 1 sibling, 0 replies; 11+ messages in thread From: Omair Javaid @ 2014-01-15 18:39 UTC (permalink / raw) To: Pedro Alves; +Cc: gdb-patches On 3 December 2013 02:16, Omair Javaid <omair.javaid@linaro.org> wrote: > > On 10/01/2013 08:34 PM, Pedro Alves wrote: >> On 10/01/2013 09:32 AM, Omair Javaid wrote: >>> On 19 September 2013 20:53, Pedro Alves <palves@redhat.com> wrote: >>>> Please don't top post. >>>> >>>> On 09/19/2013 04:23 PM, Omair Javaid wrote: >>>>> Thanks everyone for the feedback. >>>>> >>>>> I am getting following problem with 1byte text section in the dw2-dos-drive.exp >>>>> >>>>> (gdb) PASS: gdb.dwarf2/dw2-dos-drive.exp: set breakpoint pending off >>>>> break 'z:file.c':func >>>>> Cannot access memory at address 0x0 >>>>> >>>>> When I change this to 4bytes the problem gets fixed. That is why I >>>>> thought this could be an unaligned illegal memory access but I accept >>>>> that the above comments verify that its not a alignment issue. >>>>> >>>>> Can anyone help me figure out what could be the cause of this problem? >>>> >>>> Breakpoint instructions on ARM are 4-byte wide. It sounds like >>>> GDB is trying to read the memory at the breakpoint's address, and >>>> that fails (that error message comes from GDB, not the program). >>>> AFAICS, the test doesn't execute the compiled object's code, so >>>> GDB will try to read memory from the binary's sections. As the >>>> section is only 1 byte long, and probably no other section is allocated >>>> contiguously, that'll fail... To confirm, debug GDB under GDB, >>>> and put a break on throw_it or some such. Then work up the stack >>>> to see where that is thrown, and why. >>>> >>>> -- >>>> Pedro Alves >>>> >>> >>> I have verified the error is being thrown by gdb while its unable to >>> read the 4byte breakpoint address. >>> Heres the call stack: >>> Thread [1] (Suspended: Breakpoint hit.) >>> 38 throw_error() exceptions.c:444 0x0016728c >>> 37 memory_error() corefile.c:204 0x001d1fcc >>> 36 read_memory() corefile.c:223 0x001d201a >>> 35 read_memory_unsigned_integer() corefile.c:312 0x001d2166 >>> 34 arm_skip_prologue() arm-tdep.c:1452 0x00054270 >> >> Right, though this is actually parsing the prologue: >> >> static CORE_ADDR >> arm_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR pc) >> { >> ... >> for (skip_pc = pc; skip_pc < limit_pc; skip_pc += 4) >> { >> inst = read_memory_unsigned_integer (skip_pc, 4, byte_order_for_code); >> >> Some ports detect errors and instead return the PC as far >> as it was managed to be skip. >> E.g. rs6000-tdep.c:skip_prologue (rs6000==PowerPC): >> >> /* Fetch the instruction and convert it to an integer. */ >> if (target_read_memory (pc, buf, 4)) >> break; >> op = extract_unsigned_integer (buf, 4, byte_order); >> >> But not all do that. SPARC also doesn't throw. But others do throw >> an error like ARM. I tried SH and that throws error like ARM; MIPS >> and xtensa, from inspection, look like they'll throw but I haven't >> tried it. AAarch64 throws like ARM, but that's not surprising. >> Anyway, there's no standard. >> >>> 33 gdbarch_skip_prologue() gdbarch.c:2603 0x00176e5c >>> 32 skip_prologue_sal() symtab.c:2869 0x0013dad2 >>> 31 find_function_start_sal() symtab.c:2782 0x0013d9aa >>> 30 symbol_to_sal() linespec.c:3622 0x0014f722 >>> 29 convert_linespec_to_sals() linespec.c:2028 0x0014d6fa >>> 28 parse_linespec() linespec.c:2319 0x0014dc04 >>> 27 decode_line_full() linespec.c:2430 0x0014df44 >>> 26 parse_breakpoint_sals() breakpoint.c:9323 0x00108560 >> ... >> >>> I guess only way to address it is to either use the patch I have >>> posted or may be disable the test for arm? Any suggestions? >> >> Another other way to handle this would be to make the prologue >> scanner cope with this, and not error out, like some ports do. But >> it's not clear at all to me that's a useful behavior. Even if we >> pretended we found the end of the prologue in this case, the address >> we would find in this particular case would never be a valid address >> to put a breakpoint at (the function's first address). If we tried >> setting a breakpoint there, who knows what is it would be overwritten >> by the bytes that fall off the section (we can be 99.99% sure >> the next section would be aligned, and the gap wouldn't be used >> for anything, but still... So, I think it might be better to leave >> the scanner as is, throwing the error while it has context about >> it, and let the user (or higher-level code) decide what to do. >> >> Another way to tackle this could be to actually disable prologue >> skipping, by setting the breakpoint at exactly the func's first >> instruction, with the '*'/address operator: >> >> -gdb_test "break 'z:file.c':func" {Breakpoint [0-9]+ at .*} >> +gdb_test "break *'z:file.c'::func" {Breakpoint [0-9]+ at .*} >> >> This doesn't actually work, though I think that's a bug. I'll >> file a PR. >> >> But, even if it did, that converts a linespec to an expression, >> which may not be a universal solution, as tests with this issue >> might need to use a "real" linespec... >> >> So, in the end, it'd be fine with me to just go in the >> direction of your original patch then. But I think it deserves >> a comment: >> >> pc_start: >> /* Enough space to fit one instruction. */ >> - .byte 0 >> + .4byte 0 >> pc_end: >> >> Could you resend your patch, with that change, a fixed commit >> log description and fixed ChangeLog? >> >> Thanks, >> > > Sorry about responding late to this. I have attached the patch along with commit message and a ChangeLog. > > Commit Log Message: > > Avoid test failure due to error thrown from skip prologue code by > an illegal memory access in case of single byte text section > > gdb/testsuite/ChangeLog: > > 2013-12-02 Omair Javaid <Omair.Javaid@linaro.org> > > * gdb.dwarf2/dw2-dos-drive.S: Changed text section size to 4 bytes > > --- > gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S b/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S > index 682ba4e..f226912 100644 > --- a/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S > +++ b/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S > @@ -15,7 +15,7 @@ > > .text > pc_start: > - .byte 0 > + .4byte 0 > pc_end: > > .section .debug_info > -- Ping! OK to commit? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-dos-drive failure on ARM 2013-12-02 21:17 ` Omair Javaid 2014-01-15 18:39 ` Omair Javaid @ 2014-01-16 10:25 ` Pedro Alves 2014-01-16 10:35 ` Omair Javaid 1 sibling, 1 reply; 11+ messages in thread From: Pedro Alves @ 2014-01-16 10:25 UTC (permalink / raw) To: Omair Javaid; +Cc: gdb-patches, Patch Tracking On 12/02/2013 09:16 PM, Omair Javaid wrote: > On 10/01/2013 08:34 PM, Pedro Alves wrote: >> So, in the end, it'd be fine with me to just go in the >> direction of your original patch then. But I think it deserves >> a comment: >> >> pc_start: >> /* Enough space to fit one instruction. */ >> - .byte 0 >> + .4byte 0 >> pc_end: >> >> Could you resend your patch, with that change, a fixed commit >> log description and fixed ChangeLog? > Sorry about responding late to this. I have attached the patch along with commit message and a ChangeLog. > > Commit Log Message: > > Avoid test failure due to error thrown from skip prologue code by > an illegal memory access in case of single byte text section Period at end of sentences. That log if very incomplete though. See below for what I suggest. (Note I tweaked the subject too) The best/easiest is to write that in the git commit log in your local tree, and send out the commit exactly as you propose to push. > gdb/testsuite/ChangeLog: > > 2013-12-02 Omair Javaid <Omair.Javaid@linaro.org> > > * gdb.dwarf2/dw2-dos-drive.S: Changed text section size to 4 bytes Period at end of sentence. > > --- > gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S b/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S > index 682ba4e..f226912 100644 > --- a/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S > +++ b/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S > @@ -15,7 +15,7 @@ > > .text > pc_start: > - .byte 0 > + .4byte 0 Still misses comment. The version below adds one similar to what I suggested before. If this looks good to you, I'll push it. Thanks. -- >8 -- From: Omair Javaid <omair.javaid@linaro.org> Subject: Fix testsuite/gdb.dwarf2/dw2-dos-drive.exp on ARM. This test currently fails on ARM: (gdb) PASS: gdb.dwarf2/dw2-dos-drive.exp: set breakpoint pending off break 'z:file.c':func Cannot access memory at address 0x0 The error is GDB trying to read the prologue at the breakpoint's address, and failing: 38 throw_error() exceptions.c:444 0x0016728c 37 memory_error() corefile.c:204 0x001d1fcc 36 read_memory() corefile.c:223 0x001d201a 35 read_memory_unsigned_integer() corefile.c:312 0x001d2166 34 arm_skip_prologue() arm-tdep.c:1452 0x00054270 static CORE_ADDR arm_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR pc) { ... for (skip_pc = pc; skip_pc < limit_pc; skip_pc += 4) { inst = read_memory_unsigned_integer (skip_pc, 4, byte_order_for_code); The test doesn't execute the compiled object's code, so GDB will try to read memory from the binary's sections. Instructions on ARM are 4-byte wide, and thus ARM's prologue scanner reads in 4-byte chunks. As the section 'func' is put at is only 1 byte long, and no other section is allocated contiguously: ... Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000001 00000000 00000000 00000034 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE ... ... the exec target fails the read the 4 bytes. Fix this by increasing the function's size. gdb/testsuite/ChangeLog: 2014-01-16 Omair Javaid <Omair.Javaid@linaro.org> * gdb.dwarf2/dw2-dos-drive.S: Increase text section size to 4 bytes. --- gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S b/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S index 6e9d360..84006f7 100644 --- a/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S +++ b/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S @@ -15,7 +15,8 @@ .text pc_start: - .byte 0 + /* Enough space to fit at least one instruction. */ + .4byte 0 pc_end: .section .debug_info -- 1.7.11.7 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-dos-drive failure on ARM 2014-01-16 10:25 ` Pedro Alves @ 2014-01-16 10:35 ` Omair Javaid 2014-01-16 10:58 ` Pedro Alves 0 siblings, 1 reply; 11+ messages in thread From: Omair Javaid @ 2014-01-16 10:35 UTC (permalink / raw) To: Pedro Alves; +Cc: gdb-patches, Patch Tracking On Thu 16 Jan 2014 03:25:34 PM PKT, Pedro Alves wrote: > On 12/02/2013 09:16 PM, Omair Javaid wrote: >> On 10/01/2013 08:34 PM, Pedro Alves wrote: >>> So, in the end, it'd be fine with me to just go in the >>> direction of your original patch then. But I think it deserves >>> a comment: >>> >>> pc_start: >>> /* Enough space to fit one instruction. */ >>> - .byte 0 >>> + .4byte 0 >>> pc_end: >>> >>> Could you resend your patch, with that change, a fixed commit >>> log description and fixed ChangeLog? > >> Sorry about responding late to this. I have attached the patch along with commit message and a ChangeLog. >> >> Commit Log Message: >> >> Avoid test failure due to error thrown from skip prologue code by >> an illegal memory access in case of single byte text section > > Period at end of sentences. That log if very incomplete though. > See below for what I suggest. (Note I tweaked the subject too) > > The best/easiest is to write that in the git commit log in your > local tree, and send out the commit exactly as you propose > to push. > >> gdb/testsuite/ChangeLog: >> >> 2013-12-02 Omair Javaid <Omair.Javaid@linaro.org> >> >> * gdb.dwarf2/dw2-dos-drive.S: Changed text section size to 4 bytes > > Period at end of sentence. > >> >> --- >> gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S b/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S >> index 682ba4e..f226912 100644 >> --- a/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S >> +++ b/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S >> @@ -15,7 +15,7 @@ >> >> .text >> pc_start: >> - .byte 0 >> + .4byte 0 > > Still misses comment. The version below adds one similar to > what I suggested before. > > If this looks good to you, I'll push it. > > Thanks. > > -- >8 -- > From: Omair Javaid <omair.javaid@linaro.org> > Subject: Fix testsuite/gdb.dwarf2/dw2-dos-drive.exp on ARM. > > This test currently fails on ARM: > > (gdb) PASS: gdb.dwarf2/dw2-dos-drive.exp: set breakpoint pending off > break 'z:file.c':func > Cannot access memory at address 0x0 > > The error is GDB trying to read the prologue at the breakpoint's > address, and failing: > > 38 throw_error() exceptions.c:444 0x0016728c > 37 memory_error() corefile.c:204 0x001d1fcc > 36 read_memory() corefile.c:223 0x001d201a > 35 read_memory_unsigned_integer() corefile.c:312 0x001d2166 > 34 arm_skip_prologue() arm-tdep.c:1452 0x00054270 > > static CORE_ADDR > arm_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR pc) > { > ... > for (skip_pc = pc; skip_pc < limit_pc; skip_pc += 4) > { > inst = read_memory_unsigned_integer (skip_pc, 4, byte_order_for_code); > > > The test doesn't execute the compiled object's code, so GDB will try > to read memory from the binary's sections. Instructions on ARM are > 4-byte wide, and thus ARM's prologue scanner reads in 4-byte chunks. > As the section 'func' is put at is only 1 byte long, and no other > section is allocated contiguously: > > ... > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 00000001 00000000 00000000 00000034 2**0 > CONTENTS, ALLOC, LOAD, READONLY, CODE > ... > > ... the exec target fails the read the 4 bytes. > > Fix this by increasing the function's size. > > gdb/testsuite/ChangeLog: > 2014-01-16 Omair Javaid <Omair.Javaid@linaro.org> > > * gdb.dwarf2/dw2-dos-drive.S: Increase text section size to 4 > bytes. > --- > gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S b/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S > index 6e9d360..84006f7 100644 > --- a/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S > +++ b/gdb/testsuite/gdb.dwarf2/dw2-dos-drive.S > @@ -15,7 +15,8 @@ > > .text > pc_start: > - .byte 0 > + /* Enough space to fit at least one instruction. */ > + .4byte 0 > pc_end: > > .section .debug_info Changes look good. Thanks. Kindly go ahead and push. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-dos-drive failure on ARM 2014-01-16 10:35 ` Omair Javaid @ 2014-01-16 10:58 ` Pedro Alves 0 siblings, 0 replies; 11+ messages in thread From: Pedro Alves @ 2014-01-16 10:58 UTC (permalink / raw) To: Omair Javaid; +Cc: gdb-patches, Patch Tracking On 01/16/2014 10:35 AM, Omair Javaid wrote: > Changes look good. Thanks. > Kindly go ahead and push. Pushed. -- Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-01-16 10:58 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CANW4E-3h4UODqrXEjP2Z8AmZa+eYtXnTY337EosXTSE6016uGQ@mail.gmail.com>
2013-07-15 10:27 ` [PATCH] testsuite/gdb.dwarf2: Fix for dw2-dos-drive failure on ARM Omair Javaid
2013-07-30 15:38 ` Pedro Alves
2013-09-19 15:23 ` Omair Javaid
2013-09-19 15:53 ` Pedro Alves
2013-10-01 8:32 ` Omair Javaid
2013-10-01 15:34 ` Pedro Alves
2013-12-02 21:17 ` Omair Javaid
2014-01-15 18:39 ` Omair Javaid
2014-01-16 10:25 ` Pedro Alves
2014-01-16 10:35 ` Omair Javaid
2014-01-16 10:58 ` Pedro Alves
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).