Re: [patch] Re: Advice on fixing gdb/12528

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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