This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Re: Advice on fixing gdb/12528
On Tue, 15 Mar 2011 02:39:39 +0100, Paul Pluzhnikov wrote:
> ChangeLog:
>
> 2011-03-14 Paul Pluzhnikov <ppluzhnikov@google.com>
>
> PR gdb/12528
> * dwarf2read.c (noop_record_line): New function.
> (dwarf_decode_lines): Ignore line tables for GCd functions.
>
> testsuite/ChangeLog:
>
> 2011-03-14 Paul Pluzhnikov <ppluzhnikov@google.com>
>
> PR gdb/12528
> * gdb.dwarf2/break-on-linker-gcd-function.exp: New test.
> * gdb.dwarf2/break-on-linker-gcd-function.cc: New file.
It seems correct to me, please check it in.
> case DW_LNE_set_address:
> address = read_address (abfd, line_ptr, cu, &bytes_read);
> op_index = 0;
> line_ptr += bytes_read;
> +
> + if (address == 0 && !dwarf2_per_objfile->has_section_at_zero)
> + /* This line table is for a function which has been
> + GCd by the linker. Ignore it. PR gdb/12528 */
> + p_record_line = noop_record_line;
There could be a `complaint' call here, correct linker/postprocessor would
discard the .debug_line part along.
> +
> address += baseaddr;
> break;
This opcode is the only one settings ADDRESS to absolute value (using
BASEADDR) so I believe it is correct.
> +# This accepts e.g. "Breakpoint 1 at 0x40968a" (fixed GDB)
> +# but rejects e.g. "Breakpoint 1 at 0x4" (broken GDB).
> +gdb_test "b [gdb_get_line_number "gdb break here"]" "Breakpoint \[0-9\] at 0x\[0-9a-f\]\[0-9a-f\]+: .*"
I was thinking if some prologue cannot be >=0x10 due to some alignments etc.
But neither ia64 (0x1 - still in the first bundle) nor s390x (0xa) exceed the
0x10 limit so it is probably OK. A regression would be found at least on x86*
boxes anyway.
Thanks,
Jan