external/binutils.git
10 years agoInclude common-exceptions.h in common-defs.h
Gary Benson [Wed, 8 Oct 2014 08:33:22 +0000 (09:33 +0100)]
Include common-exceptions.h in common-defs.h

This commit includes common-exceptions.h in common-defs.h and removes
all other inclusions.

gdb/ChangeLog:

* common/common-defs.h: Include common-exceptions.h.
* exceptions.h: Do not include common-exceptions.h.

gdb/gdbserver/ChangeLog:

* server.h: Do not include common-exceptions.h.

10 years agoInclude cleanups.h in common-defs.h
Gary Benson [Wed, 8 Oct 2014 08:33:22 +0000 (09:33 +0100)]
Include cleanups.h in common-defs.h

This commit includes cleanups.h in common-defs.h and removes all other
inclusions.

gdb/ChangeLog:

* common/common-defs.h: Include cleanups.h.
* common/common-exceptions.c: Do not include cleanups.h.
* utils.h: Likewise.

gdb/gdbserver/ChangeLog:

* server.h: Do not include cleanups.h.

10 years agoRemove spurious exceptions.h inclusions
Gary Benson [Wed, 8 Oct 2014 08:33:22 +0000 (09:33 +0100)]
Remove spurious exceptions.h inclusions

defs.h includes utils.h, and utils.h includes exceptions.h.  All GDB
.c files include defs.h as their first line, so no file other than
utils.h needs to include exceptions.h.  This commit removes all such
inclusions.

gdb/ChangeLog:

* ada-lang.c: Do not include exceptions.h.
* ada-valprint.c: Likewise.
* amd64-tdep.c: Likewise.
* auto-load.c: Likewise.
* block.c: Likewise.
* break-catch-throw.c: Likewise.
* breakpoint.c: Likewise.
* btrace.c: Likewise.
* c-lang.c: Likewise.
* cli/cli-cmds.c: Likewise.
* cli/cli-interp.c: Likewise.
* cli/cli-script.c: Likewise.
* completer.c: Likewise.
* corefile.c: Likewise.
* corelow.c: Likewise.
* cp-abi.c: Likewise.
* cp-support.c: Likewise.
* cp-valprint.c: Likewise.
* darwin-nat.c: Likewise.
* dwarf2-frame-tailcall.c: Likewise.
* dwarf2-frame.c: Likewise.
* dwarf2loc.c: Likewise.
* dwarf2read.c: Likewise.
* eval.c: Likewise.
* event-loop.c: Likewise.
* event-top.c: Likewise.
* f-valprint.c: Likewise.
* frame-unwind.c: Likewise.
* frame.c: Likewise.
* gdbtypes.c: Likewise.
* gnu-v2-abi.c: Likewise.
* gnu-v3-abi.c: Likewise.
* guile/scm-auto-load.c: Likewise.
* guile/scm-breakpoint.c: Likewise.
* guile/scm-cmd.c: Likewise.
* guile/scm-frame.c: Likewise.
* guile/scm-lazy-string.c: Likewise.
* guile/scm-param.c: Likewise.
* guile/scm-symbol.c: Likewise.
* guile/scm-type.c: Likewise.
* hppa-hpux-tdep.c: Likewise.
* i386-tdep.c: Likewise.
* inf-loop.c: Likewise.
* infcall.c: Likewise.
* infcmd.c: Likewise.
* infrun.c: Likewise.
* interps.c: Likewise.
* interps.h: Likewise.
* jit.c: Likewise.
* linespec.c: Likewise.
* linux-nat.c: Likewise.
* linux-thread-db.c: Likewise.
* m32r-rom.c: Likewise.
* main.c: Likewise.
* memory-map.c: Likewise.
* mi/mi-cmd-break.c: Likewise.
* mi/mi-cmd-stack.c: Likewise.
* mi/mi-interp.c: Likewise.
* mi/mi-main.c: Likewise.
* monitor.c: Likewise.
* nto-procfs.c: Likewise.
* objc-lang.c: Likewise.
* p-valprint.c: Likewise.
* parse.c: Likewise.
* ppc-linux-tdep.c: Likewise.
* printcmd.c: Likewise.
* probe.c: Likewise.
* python/py-auto-load.c: Likewise.
* python/py-breakpoint.c: Likewise.
* python/py-cmd.c: Likewise.
* python/py-finishbreakpoint.c: Likewise.
* python/py-frame.c: Likewise.
* python/py-framefilter.c: Likewise.
* python/py-function.c: Likewise.
* python/py-gdb-readline.c: Likewise.
* python/py-inferior.c: Likewise.
* python/py-infthread.c: Likewise.
* python/py-lazy-string.c: Likewise.
* python/py-linetable.c: Likewise.
* python/py-param.c: Likewise.
* python/py-prettyprint.c: Likewise.
* python/py-symbol.c: Likewise.
* python/py-type.c: Likewise.
* python/py-value.c: Likewise.
* python/python-internal.h: Likewise.
* python/python.c: Likewise.
* record-btrace.c: Likewise.
* record-full.c: Likewise.
* regcache.c: Likewise.
* remote-fileio.c: Likewise.
* remote-mips.c: Likewise.
* remote.c: Likewise.
* rs6000-aix-tdep.c: Likewise.
* rs6000-nat.c: Likewise.
* skip.c: Likewise.
* solib-darwin.c: Likewise.
* solib-dsbt.c: Likewise.
* solib-frv.c: Likewise.
* solib-ia64-hpux.c: Likewise.
* solib-spu.c: Likewise.
* solib-svr4.c: Likewise.
* solib.c: Likewise.
* spu-tdep.c: Likewise.
* stack.c: Likewise.
* stap-probe.c: Likewise.
* symfile-mem.c: Likewise.
* symmisc.c: Likewise.
* target.c: Likewise.
* thread.c: Likewise.
* top.c: Likewise.
* tracepoint.c: Likewise.
* tui/tui-interp.c: Likewise.
* typeprint.c: Likewise.
* utils.c: Likewise.
* valarith.c: Likewise.
* valops.c: Likewise.
* valprint.c: Likewise.
* value.c: Likewise.
* varobj.c: Likewise.
* windows-nat.c: Likewise.
* xml-support.c: Likewise.

10 years agodaily update
Alan Modra [Tue, 7 Oct 2014 23:00:35 +0000 (09:30 +1030)]
daily update

10 years agodaily update
Alan Modra [Mon, 6 Oct 2014 23:00:33 +0000 (09:30 +1030)]
daily update

10 years agodaily update
Alan Modra [Sun, 5 Oct 2014 23:00:41 +0000 (09:30 +1030)]
daily update

10 years agoMIPS: Rewrite `add_offset_16' to match its name
Maciej W. Rozycki [Sun, 5 Oct 2014 22:37:53 +0000 (23:37 +0100)]
MIPS: Rewrite `add_offset_16' to match its name

A helper function called `add_offset_16' is used by
`extended_mips16_next_pc' to calculate branch destinations.  Weirdly
enough the helper does not do what the name suggests and rather than
doing its work for a 16-bit immediate branch offset it makes its
calculations on a 26-bit immediate target used by JAL and JALX
instructions.  Furthermore the JAL/JALX calculation is only needed once
by `extended_mips16_next_pc' while a 16-bit branch offset calculation
is made inline several times across `extended_mips16_next_pc'.

This change therefore replaces the contents of `add_offset_16' with the
16-bit branch offset calculation and updates `extended_mips16_next_pc'
accordingly.

* mips-tdep.c (add_offset_16): Rewrite to implement what the
name implies.
(extended_mips16_next_pc): Update accordingly.

10 years agoMIPS: Correct heuristic prologue termination conditions
Maciej W. Rozycki [Sun, 5 Oct 2014 21:39:52 +0000 (22:39 +0100)]
MIPS: Correct heuristic prologue termination conditions

This change addresses a regression in gdb.dwarf2/dw2-skip-prologue.exp
across MIPS16 multilibs:

(gdb) file .../gdb.dwarf2/dw2-skip-prologue
Reading symbols from .../gdb.d/gdb.dwarf2/dw2-skip-prologue...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
warning: Breakpoint address adjusted from 0x00400725 to 0x00400721.
Breakpoint 1 at 0x400721
(gdb) set remotetimeout 5
(gdb) kill
The program is not being run.
(gdb)
[...]
target remote ...:2345
Reading symbols from .../mips16/lib/ld.so.1...done.
warning: Breakpoint address adjusted from 0x00400725 to 0x00400721.
warning: Breakpoint address adjusted from 0x00400725 to 0x00400721.
0x2aaa8e81 in __start () from .../mips16/lib/ld.so.1
(gdb) continue
Continuing.
warning: Breakpoint address adjusted from 0x00400725 to 0x00400721.
warning: Breakpoint 1 address previously adjusted from 0x00400725 to
0x00400721.
Breakpoint 1, 0x00400721 in main ()
(gdb) break func
Breakpoint 2 at 0x4006a1: func. (2 locations)
(gdb) continue
Continuing.
warning: GDB can't find the start of the function at 0x4006dd.

    GDB is unable to find the start of the function at 0x4006dd
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x4006dd for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.

Program received signal SIGBUS, Bus error.
0x0040072b in main ()
(gdb) FAIL: gdb.dwarf2/dw2-skip-prologue.exp: continue to breakpoint: func

-- notice the breakpoint adjustment messages that are already a bad
sign.  These happen when a breakpoint is requested in a branch delay
slot and are not supposed to happen unless explicitly requested with an
address pointing to a branch delay slot instruction.  No symbol or line
debug information is supposed to direct GDB to place a breakpoint in a
delay slot.

Here's how `main' looks like:

00400718 <main>:
  400718: 64f5       save 40,ra,s0-s1
  40071a: 1a00 01a8  jal 4006a0 <func>
  40071e: 0104       addiu s1,sp,16
  400720: 1a00 01b7  jal 4006dc <func+0x3c>
  400724: 6702       move s0,v0
  400726: e049       addu v0,s0,v0
  400728: 65b9       move sp,s1
  40072a: 6473       restore 24,ra,s0-s1
  40072c: e8a0       jrc ra
  40072e: 6500       nop

-- so 0x400725 is the MIPS16 instruction address of the first MOVE
instruction seen above, in a delay slot of the preceding JAL instruction
indeed.  This test case arranges for `main' to have no debug information
so it is one of the heuristic prologue scanners, `mips16_scan_prologue'
specifically in this case, that is responsible for finding the right
location for the breakpoint to place.

In this case the prologue really ends with the ADDIU instruction,
reordered into the delay slot of the first JAL instruction.  Of course
we can't place the breakpoint for `main' after it as by doing so we'll
let `func' to be called before hitting this breakpoint.  So the
breakpoint has to go at the JAL instruction instead, or 0x40071b.

To make a general case out of it we must never consider any jump or
branch instruction to be a part of a function's prologue.  In the
presence of a jump or branch at the beginning of a function the furthest
instruction examined for the purpose of constructing frame information
can be one in the delay slot of that jump or branch if present, and
otherwise -- that is when the jump or branch is compact and has no delay
slot -- the instruction immediately preceding the jump or branch.

This change implements that approach across prologue scanners for the
three instruction ISAs.  In implementing it I have factored out code
from the existing `*_instruction_has_delay_slot' handlers to be shared
and a side effect for the microMIPS implementation is it now always
fetches the second 16-bit halfword of 32-bit instructions even if it
eventually is not going to be needed.  I think it's an acceptable
tradeoff for the purpose of code sharing.

To make things more consistent I also carried logic from
`micromips_scan_prologue' over to the other two scanners to accept (and
ignore) a single non-prologue non-control transfer instruction reordered
by the compiler into the prologue.  While doing this I simplified the
exit path from the scan loop such that `end_prologue_addr' is set only
once.  This made some concerns expressed in comments no longer
applicable, although even before they were not valid.

I have not fixed the logic around `load_immediate_bytes' in
`mips32_scan_prologue' though, it remains broken, although I took care
not to break it more.  An approach similar to one taken for handling
larger stack adjustments in `micromips_scan_prologue' will have to be
eventually implemented here.

For regression testing I used my usual choice of the mips-linux-gnu
target and the following multilibs:

-EB
-EB -msoft-float
-EB -mips16
-EB -mips16 -msoft-float
-EB -mmicromips
-EB -mmicromips -msoft-float
-EB -mabi=n32
-EB -mabi=n32 -msoft-float
-EB -mabi=64
-EB -mabi=64 -msoft-float

and the -EL variants of same.

That removed gdb.dwarf2/dw2-skip-prologue.exp failures across MIPS16
multilibs, the test log now shows:

(gdb) file .../gdb.dwarf2/dw2-skip-prologue
Reading symbols from .../gdb.d/gdb.dwarf2/dw2-skip-prologue...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x40071b
(gdb) set remotetimeout 5
(gdb) kill
The program is not being run.
(gdb)
[...]
target remote ...:2345
Reading symbols from .../mips16/lib/ld.so.1...done.
0x2aaa8e81 in __start () from .../mips16/lib/ld.so.1
(gdb) continue
Continuing.

Breakpoint 1, 0x0040071b in main ()
(gdb) break func
Breakpoint 2 at 0x4006a1: func. (2 locations)
(gdb) continue
Continuing.

Breakpoint 2, func (param=0) at main.c:5
5    This program is free software; you can redistribute it and/or modify
(gdb) PASS: gdb.dwarf2/dw2-skip-prologue.exp: continue to breakpoint: func

-- so things look like intended.

That also did regress, again across MIPS16 multilibs, another test case,
gdb.base/step-symless.exp:

(gdb) file .../gdb.d/gdb.base/step-symless
Reading symbols from .../gdb.base/step-symless...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x4006d3
(gdb) set remotetimeout 5
(gdb) kill
The program is not being run.
(gdb)
[...]
target remote ...:2345
Reading symbols from .../mips16/lib/ld.so.1...done.
0x2aaa8e81 in __start () from .../mips16/lib/ld.so.1
(gdb) continue
Continuing.

Breakpoint 1, 0x004006d3 in main ()
(gdb) break symful
Breakpoint 2 at 0x4006a5
(gdb) step
Single stepping until exit from function main,
which has no line number information.
warning: GDB can't find the start of the function at 0x4006b9.

    GDB is unable to find the start of the function at 0x4006b9
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x4006b9 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
0x004006b9 in ?? ()
(gdb) FAIL: gdb.base/step-symless.exp: step

-- but that is actually a good sign.  Here `main', again, has no debug
information and code involved looks like:

004006a0 <symful>:
  4006a0: 6491       save 8,s1
  4006a2: 673d       move s1,sp
  4006a4: b204       lw v0,4006b4 <symful+0x14>
  4006a6: 9a40       lw v0,0(v0)
  4006a8: 4261       addiu v1,v0,1
  4006aa: b203       lw v0,4006b4 <symful+0x14>
  4006ac: da60       sw v1,0(v0)
  4006ae: 65b9       move sp,s1
  4006b0: 6411       restore 8,s1
  4006b2: e8a0       jrc ra
  4006b4: 0041       addiu s0,sp,260
  4006b6: 0860       la s0,400834 <__libc_start_main@mips16plt+0x54>
  4006b8: 6491       save 8,s1
  4006ba: 673d       move s1,sp
  4006bc: b204       lw v0,4006cc <symful+0x2c>
  4006be: 9a40       lw v0,0(v0)
  4006c0: 4261       addiu v1,v0,1
  4006c2: b203       lw v0,4006cc <symful+0x2c>
  4006c4: da60       sw v1,0(v0)
  4006c6: 65b9       move sp,s1
  4006c8: 6411       restore 8,s1
  4006ca: e8a0       jrc ra
  4006cc: 0041       addiu s0,sp,260
  4006ce: 0860       la s0,40084c <__libc_start_main@mips16plt+0x6c>

004006d0 <main>:
  4006d0: 64d4       save 32,ra,s1
  4006d2: 1a00 01ae  jal 4006b8 <symful+0x18>
  4006d6: 0104       addiu s1,sp,16
  4006d8: 1a00 01a8  jal 4006a0 <symful>
  4006dc: 6500       nop
  4006de: 6740       move v0,zero
  4006e0: 65b9       move sp,s1
  4006e2: 6452       restore 16,ra,s1
  4006e4: e8a0       jrc ra
  4006e6: 6500       nop
  4006e8: 6500       nop
  4006ea: 6500       nop
  4006ec: 6500       nop
  4006ee: 6500       nop

-- and the original log:

(gdb) file .../gdb.base/step-symless
Reading symbols from .../gdb.base/step-symless...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
warning: Breakpoint address adjusted from 0x004006dd to 0x004006d9.
Breakpoint 1 at 0x4006d9
(gdb) set remotetimeout 5
(gdb) kill
The program is not being run.
(gdb)
[...]
target remote ...:2345
Reading symbols from .../mips16/lib/ld.so.1...done.
warning: Breakpoint address adjusted from 0x004006dd to 0x004006d9.
warning: Breakpoint address adjusted from 0x004006dd to 0x004006d9.
0x2aaa8e81 in __start () from .../mips16/lib/ld.so.1
(gdb) continue
Continuing.
warning: Breakpoint address adjusted from 0x004006dd to 0x004006d9.
warning: Breakpoint 1 address previously adjusted from 0x004006dd to
0x004006d9.
Breakpoint 1, 0x004006d9 in main ()
(gdb) break symful
Breakpoint 2 at 0x4006a5
(gdb) step
Single stepping until exit from function main,
which has no line number information.

Breakpoint 2, 0x004006a5 in symful ()
(gdb) PASS: gdb.base/step-symless.exp: step

So the breakpoint at `main' was actually set at an instruction after the
call to `symful+0x18' aka `symless' and the test only passed because
single-stepping through `symless' wasn't actually done at all.  With
this change in place this test fails for MIPS16 multilibs consistently
with all the other multilibs where it already failed in this manner
previously.

* mips-tdep.c (mips16_instruction_is_compact_branch): New
function.
(micromips_instruction_is_compact_branch): Likewise.
(mips16_scan_prologue): Terminate scanning upon seeing a branch
or a compact jump, reaching a jump delay slot, or seeing a
second non-prologue instruction.
(micromips_scan_prologue): Also terminate scanning upon seeing a
compact branch or jump, or reaching a branch or jump delay slot.
(mips32_scan_prologue): Terminate scanning upon reaching a branch
or jump delay slot, or seeing a second non-prologue instruction.
(mips32_instruction_has_delay_slot): Retain instruction
examination code only, update arguments accordingly and move
instruction fetch pieces to...
(mips32_insn_at_pc_has_delay_slot): ... this new function.
(micromips_instruction_has_delay_slot): Likewise and to...
(micromips_insn_at_pc_has_delay_slot): ... this new function.
(mips16_instruction_has_delay_slot): Likewise and to...
(mips16_insn_at_pc_has_delay_slot): ... this new function.
(mips_single_step_through_delay): Update accordingly.
(mips_adjust_breakpoint_address): Likewise.

10 years agoMIPS: Correct MUSTBE32 interpretation in delay slot handling
Maciej W. Rozycki [Sun, 5 Oct 2014 20:50:47 +0000 (21:50 +0100)]
MIPS: Correct MUSTBE32 interpretation in delay slot handling

This change addresses `micromips_instruction_has_delay_slot' and
`mips16_instruction_has_delay_slot' that both incorrectly interpret
their MUSTBE32 argument.  Their callers assume that when the flag is
clear these functions will return 1 when any non-compact jump or branch
instruction is present at ADDR, while in fact they will only return 1
for 16-bit such instructions only.  This change makes the implementation
match the expectations.

* mips-tdep.c (micromips_instruction_has_delay_slot): When
!mustbe32 also return 1 for 32-bit instructions.
(mips16_instruction_has_delay_slot): Likewise.  Add an
explanatory comment.

10 years agodaily update
Alan Modra [Sat, 4 Oct 2014 23:00:54 +0000 (09:30 +1030)]
daily update

10 years agoDiscard zero address range eh_frame FDEs
Alan Modra [Sat, 4 Oct 2014 06:23:58 +0000 (15:53 +0930)]
Discard zero address range eh_frame FDEs

These are useless because they can't match any address.  In fact,
worse than useless because the .eh_frame_hdr lookup table matching
addresses to FDEs does not contain information about the FDE range.
The table is sorted by address;  Range is inferred by the address
delta from one entry to the next.  So if a zero address range FDE is
followed by a normal non-zero range FDE for the same address,
everything is good.  However, the qsort could just as easily sort the
FDEs in the other order, in which case the normal FDE would
effectively be seen to have a zero range.

bfd/
PR 17447
* elf-bfd.h (struct eh_cie_fde): Comment re NULL u.fde.cie_inf.
* elf-eh-frame.c (_bfd_elf_parse_eh_frame): Mark zero address
range FDEs for discarding.
(vma_compare): Sort on range after address.
(_bfd_elf_gc_mark_fdes): Test for NULL u.fde.cie_inf.
(_bfd_elf_discard_section_eh_frame): Likewise.  Write "FDE" in
error message rather than "fde".
(_bfd_elf_write_section_eh_frame_hdr): Write "PC" and "FDE" in
error message.
ld/testsuite/
* ld-elf/eh1.s: Don't create FDEs with zero address ranges.
* ld-elf/eh3.s: Likewise.
* ld-elf/eh1.d, * ld-elf/eh2.d, * ld-elf/eh3.d: Adjust.
* ld-mips-elf/eh-frame1-n32.d: Warning match update.
* ld-mips-elf/eh-frame1-n64.d: Likewise.
* ld-mips-elf/eh-frame2-n32.d: Likewise.
* ld-mips-elf/eh-frame2-n64.d: Likewise.

10 years agodaily update
Alan Modra [Sat, 4 Oct 2014 00:00:53 +0000 (09:30 +0930)]
daily update

10 years agoAdd aarch64 to list of targets that support gold.
Jing Yu [Fri, 3 Oct 2014 21:48:14 +0000 (14:48 -0700)]
Add aarch64 to list of targets that support gold.

This patch was committed to GCC trunk as revision 215865.
2014-10-03  Jing Yu  <jingyu@google.com>
* configure.ac: Add aarch64 to list of targets that support gold.
* configure: Regenerate.

10 years agoAlso mark ELF solib trampoline minimal symbols special
Maciej W. Rozycki [Fri, 3 Oct 2014 16:38:39 +0000 (17:38 +0100)]
Also mark ELF solib trampoline minimal symbols special

In installing minimal symbols for ELF shared library trampolines
we "forget" to make individual symbols special where required.  This
leads to problems on the MIPS target using microMIPS SVR4 lazy stubs.
Lacking the special annotation these stubs are treated as standard
MIPS code and this makes GDB insert the wrong software breakpoint
instruction, breaking e.g. single-stepping through these stubs.  This
is not a very frequent scenario as microMIPS SVR4 lazy stubs are
typically only used in shared libraries with the main executable
using PLT, handled elsewhere.  Still it triggers e.g. when a software
watchpoint has been installed.  The symptom is SIGILL or the program
going astray, depending on the endianness.  Disassembly of these stubs
is also wrong.

* elfread.c (elf_symtab_read): Also mark solib trampoline minimal
symbols special.

10 years agoAvoid software breakpoint's instruction shadow inconsistency
Maciej W. Rozycki [Fri, 3 Oct 2014 11:44:58 +0000 (12:44 +0100)]
Avoid software breakpoint's instruction shadow inconsistency

This change:

commit b775012e845380ed4c7421a1b87caf7bfae39f5f
Author: Luis Machado <luisgpm@br.ibm.com>
Date:   Fri Feb 24 15:10:59 2012 +0000

    2012-02-24  Luis Machado  <lgustavo@codesourcery.com>

* remote.c (remote_supports_cond_breakpoints): New forward
declaration.
[...]

changed the way breakpoints are inserted and removed such that
`insert_bp_location' can now be called with the breakpoint being handled
already in place, while previously the call was only ever made for
breakpoints that have not been put in place.  This in turn caused an
issue for software breakpoints and targets for which a breakpoint's
`placed_address' may not be the same as the original requested address.

The issue is `insert_bp_location' overwrites the previously adjusted
value in `placed_address' with the original address, that is only
replaced back with the correct adjusted address later on when
`gdbarch_breakpoint_from_pc' is called.  Meanwhile there's a window
where the value in `placed_address' does not correspond to data stored
in `shadow_contents', leading to incorrect instruction bytes being
supplied when `one_breakpoint_xfer_memory' is called to supply the
instruction overlaid by the breakpoint.

And this is exactly what happens on the MIPS target with software
breakpoints placed in microMIPS code.  In this case not only
`placed_address' is not the original address because of the ISA bit, but
`mips_breakpoint_from_pc' has to read the original instruction to
determine which one of the two software breakpoint instruction encodings
to choose as well.  The 16-bit encoding is used to replace 16-bit
instructions and similarly the 32-bit one is used with 32-bit
instructions, to satisfy branch delay slot size requirements.

The mismatch between `placed_address' and the address data in
`shadow_contents' has been obtained from leads to the wrong encoding
being used in some cases, which in the case of a 32-bit software
breakpoint instruction replacing a 16-bit instruction causes corruption
to the adjacent following instruction and leads the debug session astray
if execution reaches there e.g. with a jump.

To address this problem I made the change below, that adds a
`reqstd_address' field to `struct bp_target_info' and leaves
`placed_address' unchanged once it has been set.  This ensures data in
`shadow_contents' is always consistent with `placed_address'.

This approach also has this good side effect that all the places that
examine the breakpoint's address see a consistent value, either
`reqstd_address' or `placed_address', as required.  Currently some
places see either the original or the adjusted address in
`placed_address', depending on whether they have been called before
`gdbarch_remote_breakpoint_from_pc' or afterwards.  This is in
particular true for subsequent calls to
`gdbarch_remote_breakpoint_from_pc' itself, e.g. from
`one_breakpoint_xfer_memory'.  This is also important for places like
`find_single_step_breakpoint' where a breakpoint's address is compared
to the raw value of $pc.

* breakpoint.h (bp_target_info): Add `reqstd_address' member,
update comments.
* breakpoint.c (one_breakpoint_xfer_memory): Use `reqstd_address'
for the breakpoint's address.  Don't preinitialize `placed_size'.
(insert_bp_location): Set `reqstd_address' rather than
`placed_address'.
(bp_target_info_copy_insertion_state): Also copy `placed_address'.
(bkpt_insert_location): Use `reqstd_address' for the breakpoint's
address.
(bkpt_remove_location): Likewise.
(deprecated_insert_raw_breakpoint): Likewise.
(deprecated_remove_raw_breakpoint): Likewise.
(find_single_step_breakpoint): Likewise.
* mem-break.c (default_memory_insert_breakpoint): Use
`reqstd_address' for the breakpoint's address.  Don't set
`placed_address' or `placed_size' if breakpoint contents couldn't
have been determined.
* remote.c (remote_insert_breakpoint): Use `reqstd_address' for
the breakpoint's address.
(remote_insert_hw_breakpoint): Likewise.  Don't set
`placed_address' or `placed_size' if breakpoint couldn't have been
set.
* aarch64-linux-nat.c (aarch64_linux_insert_hw_breakpoint): Use
`reqstd_address' for the breakpoint's address.
* arm-linux-nat.c (arm_linux_hw_breakpoint_initialize): Likewise.
* ia64-tdep.c (ia64_memory_insert_breakpoint): Likewise.
* m32r-tdep.c (m32r_memory_insert_breakpoint): Likewise.
* microblaze-linux-tdep.c
(microblaze_linux_memory_remove_breakpoint): Likewise.
* monitor.c (monitor_insert_breakpoint): Likewise.
* nto-procfs.c (procfs_insert_breakpoint): Likewise.
(procfs_insert_hw_breakpoint): Likewise.
* ppc-linux-nat.c (ppc_linux_insert_hw_breakpoint): Likewise.
* ppc-linux-tdep.c (ppc_linux_memory_remove_breakpoint): Likewise.
* remote-m32r-sdi.c (m32r_insert_breakpoint): Likewise.
* remote-mips.c (mips_insert_breakpoint): Likewise.
* x86-nat.c (x86_insert_hw_breakpoint): Likewise.

10 years agoMIPS bit field failures in gdb.base/store.exp
Luis Machado [Fri, 3 Oct 2014 11:21:33 +0000 (08:21 -0300)]
MIPS bit field failures in gdb.base/store.exp

On MIPS64 little endian, attempting an assignment to a bit field
that lives in a register yields the wrong result. It just corrupts
the data in the register depending on the specific position of the
bit field inside the structure.

FAIL: gdb.base/store.exp: f_1.j
FAIL: gdb.base/store.exp: f_1.k
FAIL: gdb.base/store.exp: F_1.i
FAIL: gdb.base/store.exp: F_1.j
FAIL: gdb.base/store.exp: F_1.k
FAIL: gdb.base/store.exp: f_2.j
FAIL: gdb.base/store.exp: f_2.k
FAIL: gdb.base/store.exp: F_2.i
FAIL: gdb.base/store.exp: F_2.j
FAIL: gdb.base/store.exp: F_2.k
FAIL: gdb.base/store.exp: f_3.j
FAIL: gdb.base/store.exp: f_3.k
FAIL: gdb.base/store.exp: F_3.i
FAIL: gdb.base/store.exp: F_3.j
FAIL: gdb.base/store.exp: F_3.k
FAIL: gdb.base/store.exp: f_4.j
FAIL: gdb.base/store.exp: f_4.k
FAIL: gdb.base/store.exp: F_4.i
FAIL: gdb.base/store.exp: F_4.j
FAIL: gdb.base/store.exp: F_4.k

                === gdb Summary ===

Now, GDB knows how to do bit field assignment properly, but MIPS is
one of those architectures that uses a hook for the register-to-value
conversion. Although we can properly tell when the type being passed
is a structure or union, we cannot tell when it is a bit field,
because the bit field data lives in a value structure.  Such data
only lives in a "type" structure when the parent structure is being
referenced, thus you can collect them from the flds_bnds members.

A bit field type structure looks pretty much the same as any other
primitive type like int or char, so we can't distinguish them.
Forcing more fields into the type structure wouldn't help much,
because the type structs are shared.

2014-10-03  Luis Machado  <lgustavo@codesourcery.com>

* valops.c (value_assign): Check for bit field assignments
before calling architecture-specific register value
conversion functions.

10 years ago[RFA] Stabs: Ignore N_BNSYM/N_ENSYM entry types
Pierre Muller [Fri, 3 Oct 2014 07:29:57 +0000 (09:29 +0200)]
[RFA] Stabs: Ignore N_BNSYM/N_ENSYM entry types

Trying to debug gdb with itself,
I stumbled on the following complaints
Unknown symbol type 0x2e
or
Unknown symbol type 0x4e

It appears that those corrspond to N_BNSYM and N_ENSYM,
which are MacOS extensions of stabs debugging format.
But these extensions have been used inside gcc probalby
for a while already, see:
https://gcc.gnu.org/ml/gcc/2004-08/msg00157.html

As the only purpose of these entries is to allow for removal
of stabs information if the function is removed,
it can be safely ignored by GDB.

This patch simply adds those two entry types to the list
of ignored entry type in read_dbx_symtab function.

Is this OK?

Pierre Muller

2014-10-03  Pierre Muller  <muller@sourceware.org>

* dbxread.c (read_dbx_symtab): Also ignore N_BNSYM/N_ENSYM.

10 years agodaily update
Alan Modra [Fri, 3 Oct 2014 01:15:36 +0000 (10:45 +0930)]
daily update

10 years agogdb.base/structs.c (main): Don't run forever.
Doug Evans [Thu, 2 Oct 2014 20:07:40 +0000 (13:07 -0700)]
gdb.base/structs.c (main): Don't run forever.

gdb/testsuite/ChangeLog:

* gdb.base/structs.c (main): Don't run forever.

10 years agogdb.threads/manythreads.exp: clean up and add comment
Pedro Alves [Wed, 24 Sep 2014 17:59:42 +0000 (18:59 +0100)]
gdb.threads/manythreads.exp: clean up and add comment

In git b57bacec, I said:

> With that in place, the need to delay "Program received signal FOO"
> was actually caught by the manythreads.exp test.  Without that bit, I
> was getting:
>
>   [Thread 0x7ffff7f13700 (LWP 4499) exited]
>   [New Thread 0x7ffff7f0b700 (LWP 4500)]
>   ^C
>   Program received signal SIGINT, Interrupt.
>   [New Thread 0x7ffff7f03700 (LWP 4501)]           <<< new output
>   [Switching to Thread 0x7ffff7f0b700 (LWP 4500)]
>   __GI___nptl_death_event () at events.c:31
>   31      {
>   (gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1
>
> That is, I was now getting "New Thread" lines after the "Program
> received signal" line, and the test doesn't expect them.  As the
> number of new threads discovered before and after the "Program
> received signal" output is unbounded, it's much nicer to defer
> "Program received signal" until after synching the thread list, thus
> close to the "switching to thread" output and "current frame/source"
> info:
>
>   [Thread 0x7ffff7863700 (LWP 7647) exited]
>   ^C[New Thread 0x7ffff786b700 (LWP 7648)]
>
>   Program received signal SIGINT, Interrupt.
>   [Switching to Thread 0x7ffff7fc4740 (LWP 6243)]
>   __GI___nptl_create_event () at events.c:25
>   25      {
>   (gdb) PASS: gdb.threads/manythreads.exp: stop threads 1

This commit factors out the two places in the test that are effected
by this, and adds there a destilled version of the comment above.

gdb/testsuite/
2014-10-02  Pedro Alves  <palves@redhat.com>

* gdb.threads/manythreads.exp (interrupt_and_wait): New procedure.
(top level) <stop threads 1, stop threads 2>: Use it.

10 years agoFix non-stop regressions caused by "breakpoints always-inserted off" changes
Pedro Alves [Thu, 2 Oct 2014 08:55:38 +0000 (09:55 +0100)]
Fix non-stop regressions caused by "breakpoints always-inserted off" changes

Commit a25a5a45 (Fix "breakpoint always-inserted off"; remove
"breakpoint always-inserted auto") regressed non-stop remote
debugging.

This was exposed by mi-nsintrall.exp intermittently failing with a
spurious SIGTRAP.

The problem is that when debugging with "target remote", new threads
the target has spawned but have never reported a stop aren't visible
to GDB until it explicitly resyncs its thread list with the target's.

For example, in a program like this:

 int
 main (void)
 {
   pthread_t child_thread;
   pthread_create (&child_thread, NULL, child_function, NULL);
   return 0;  <<<< set breakpoint here
 }

If the user sets a breakpoint at the "return" statement, and runs the
program, when that breakpoint hit is reported, GDB is only aware of
the main thread.  So if we base the decision to remove or insert
breakpoints from the target based on whether all the threads we know
about are stopped, we'll miss that child_thread is running, and thus
we'll remove breakpoints from the target, even through they should
still remain inserted, otherwise child_thread will miss them.

The break-while-running.exp test actually should also be exposing this
thread-list-out-of-synch problem.  That test sets a breakpoint while
the main thread is stopped, but other threads are running.  Because
other threads are running, the breakpoint is supposed to be inserted
immediately.  But, unless something forces a refetch of the thread
list, like, e.g., "info threads", GDB won't be aware of the other
threads that had been spawned by the main thread, and so won't insert
new or old breakpoints in the target.  And it turns out that the test
is exactly doing an explicit "info threads", masking out the
problem...  This commit adjust the test to exercise the case of not
issuing "info threads".  The test then fails without the GDB fix.

In the ni-nsintrall.exp case, what happens is that several threads hit
the same breakpoint, and when the first thread reports the stop,
because GDB wasn't aware other threads exist, all threads known to GDB
are found stopped, so GDB removes the breakpoints from the target.
The other threads follow up with SIGTRAPs too for that same
breakpoint, which has already been removed.  For the first few
threads, the moribund breakpoints machinery suppresses the SIGTRAPs,
but after a few events (precisely '3 * thread_count () + 1' at the
time the breakpoint was removed, see update_global_location_list), the
moribund breakpoint machinery is no longer aware of the removed
breakpoint, and the SIGTRAP is reported as a spurious stop.

The fix is naturally then to stop assuming that if no thread in the
list is executing, then the target is fully stopped.  We can't know
that until we fully sync the thread list.  Because updating the thread
list on every stop would be too much RSP traffic, I chose instead to
update it whenever we're about to present a stop to the user.

Actually updating the thread list at that point happens to be an item
I had added to the local/remote parity wiki page a while ago:

  Native GNU/Linux debugging adds new threads to the thread list as
  the program creates them "The [New Thread foo] messages". Remote
  debugging can't do that, and it's arguable whether we shouldn't even
  stop native debugging from doing that, as it hinders inferior
  performance. However, a related issue is that with remote targets
  (and gdbserver), even after the program stops, the user still needs
  to do "info threads" to pull an updated thread list. This, should
  most likely be addressed, so that GDB pulls the list itself, perhaps
  just before presenting a stop to the user.

With that in place, the need to delay "Program received signal FOO"
was actually caught by the manythreads.exp test.  Without that bit, I
was getting:

  [Thread 0x7ffff7f13700 (LWP 4499) exited]
  [New Thread 0x7ffff7f0b700 (LWP 4500)]
  ^C
  Program received signal SIGINT, Interrupt.
  [New Thread 0x7ffff7f03700 (LWP 4501)]           <<< new output
  [Switching to Thread 0x7ffff7f0b700 (LWP 4500)]
  __GI___nptl_death_event () at events.c:31
  31      {
  (gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1

That is, I was now getting "New Thread" lines after the "Program
received signal" line, and the test doesn't expect them.  As the
number of new threads discovered before and after the "Program
received signal" output is unbounded, it's much nicer to defer
"Program received signal" until after synching the thread list, thus
close to the "switching to thread" output and "current frame/source"
info:

  [Thread 0x7ffff7863700 (LWP 7647) exited]
  ^C[New Thread 0x7ffff786b700 (LWP 7648)]

  Program received signal SIGINT, Interrupt.
  [Switching to Thread 0x7ffff7fc4740 (LWP 6243)]
  __GI___nptl_create_event () at events.c:25
  25      {
  (gdb) PASS: gdb.threads/manythreads.exp: stop threads 1

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/
2014-10-02  Pedro Alves  <palves@redhat.com>

* breakpoint.c (breakpoints_should_be_inserted_now): Use
threads_are_executing.
* breakpoint.h (breakpoints_should_be_inserted_now): Add
describing comment.
* gdbthread.h (threads_are_executing): Declare.
(handle_signal_stop) <random signals>: Don't print about the
signal here if stopping.
(end_stepping_range): Don't notify observers here.
(normal_stop): Update the thread list.  If stopped by a random
signal or a stepping range ended, notify observers.
* thread.c (threads_executing): New global.
(init_thread_list): Clear 'threads_executing'.
(set_executing): Set or clear 'threads_executing'.
(threads_are_executing): New function.
(update_threads_executing): New function.
(update_thread_list): Use it.

gdb/testsuite/
2014-10-02  Pedro Alves  <palves@redhat.com>

* gdb.threads/break-while-running.exp (test): Add new
'update_thread_list' argument.  Skip "info threads" if false.
(top level): Add new 'update_thread_list' axis.

10 years agoPR17431: following execs with "breakpoint always-inserted on"
Pedro Alves [Thu, 2 Oct 2014 08:55:38 +0000 (09:55 +0100)]
PR17431: following execs with "breakpoint always-inserted on"

Following an exec with "breakpoint always-inserted on" tries to insert
breakpoints in the new image at the addresses the symbols had in the
old image.

With "always-inserted off", we see:

 gdb gdb.multi/multi-arch-exec -ex "set breakpoint always-inserted off"
 GNU gdb (GDB) 7.8.50.20140924-cvs
 ...
 (gdb) b main
 Breakpoint 1 at 0x400664: file gdb.multi/multi-arch-exec.c, line 24.
 ^^^^^^^^
 (gdb) c
 The program is not being run.
 (gdb) r
 Starting program: testsuite/gdb.multi/multi-arch-exec

 Breakpoint 1, main () at gdb/testsuite/gdb.multi/multi-arch-exec.c:24
 24        execl (BASEDIR "/multi-arch-exec-hello",
 (gdb) c
 Continuing.
 process 9212 is executing new program: gdb/testsuite/gdb.multi/multi-arch-exec-hello

 Breakpoint 1, main () at gdb/testsuite/gdb.multi/hello.c:40
 40        bar();
 (gdb) info breakpoints
 Num     Type           Disp Enb Address    What
 1       breakpoint     keep y   0x080484e4 in main at gdb/testsuite/gdb.multi/hello.c:40
 ^^^^^^^^^^
 breakpoint already hit 2 times
 (gdb)

Note how main was 0x400664 in multi-arch-exec, and 0x080484e4 in
gdb.multi/hello.

With "always-inserted on", we get:

 Breakpoint 1, main () at gdb/testsuite/gdb.multi/multi-arch-exec.c:24
 24        execl (BASEDIR "/multi-arch-exec-hello",
 (gdb) c
 Continuing.
 infrun: target_wait (-1, status) =
 infrun:   9444 [process 9444],
 infrun:   status->kind = execd
 infrun: infwait_normal_state
 infrun: TARGET_WAITKIND_EXECD
 Warning:
 Cannot insert breakpoint 1.
 Cannot access memory at address 0x400664

(gdb)

That is, GDB is trying to insert a breakpoint at 0x400664, after the
exec, and then that address happens to not be mapped at all in the new
image.

The problem is that update_breakpoints_after_exec is creating
breakpoints, which ends up in update_global_location_list immediately
inserting breakpoints if "breakpoints always-inserted" is "on".
update_breakpoints_after_exec is called very early when we see an exec
event.  At that point, we haven't loaded the symbols of the new
post-exec image yet, and thus haven't reset breakpoint's addresses to
whatever they may be in the new image.  All we should be doing in
update_breakpoints_after_exec is deleting breakpoints that no longer
make sense after an exec.  So the fix removes those breakpoint
creations.

The question is then, if not here, where are those breakpoints
re-created?  Turns out we don't need to do anything else, because at
the end of follow_exec, we call breakpoint_re_set, whose tail is also
creating exactly the same breakpoints update_breakpoints_after_exec is
currently creating:

  breakpoint_re_set (void)
  {
  ...
    create_overlay_event_breakpoint ();
    create_longjmp_master_breakpoint ();
    create_std_terminate_master_breakpoint ();
    create_exception_master_breakpoint ();
  }

A new test is added to exercise this.

Tested on x86_64 Fedora 20.

gdb/
2014-10-02  Pedro Alves  <palves@redhat.com>

PR breakpoints/17431
* breakpoint.c (update_breakpoints_after_exec): Don't create
overlay, longjmp, std terminate nor exception breakpoints here.

gdb/testsuite/
2014-10-02  Pedro Alves  <palves@redhat.com>

PR breakpoints/17431
* gdb.base/execl-update-breakpoints.c: New file.
* gdb.base/execl-update-breakpoints.exp: New file.

10 years agoReduce Hg packet (select remote general thread) bouncing
Pedro Alves [Thu, 2 Oct 2014 08:55:38 +0000 (09:55 +0100)]
Reduce Hg packet (select remote general thread) bouncing

A patch I wrote made GDB pull the thread list sooner when debugging
with target remote, and I noticed an intended consequence.  GDB
started bouncing around the currently selected remote/general thread
more frequently.  E.g.:

  Sending packet: $qTMinFTPILen#3b...Packet received: 5
 +Sending packet: $Hgp726d.726d#53...Packet received: OK
  Sending packet: $m400680,40#2f...Packet received: 85c0741455bff00d60004889e5ffd05de97bffffff0f1f00e973ffffff0f1f00554889e5c745fc00000000c745fc01000000e900000000c745fc02000000b800
 +Sending packet: $Hgp726d.7278#28...Packet received: OK
  Sending packet: $m4006b2,1#28...Packet received: e9
  Fast tracepoint 2 at 0x4006b2: file gdb/testsuite/gdb.trace/range-stepping.c, line 53.
  Sending packet: $qTStatus#49...Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes::

This ended up breaking "tstart" when one has fast tracepoints set,
because gdbserver isn't expecting an Hg packet in response to
qRelocInsn:

 (gdb) ftrace *set_point
 Fast tracepoint 3 at 0x4006b2: file gdb/testsuite/gdb.trace/range-stepping.c, line 53.
 (gdb) PASS: gdb.trace/range-stepping.exp: ftrace: ftrace *set_point
 tstart
 gdbserver: Malformed response to qRelocInsn, ignoring: Hgp2783.2783

 Target does not support this command.
 (gdb) FAIL: gdb.trace/range-stepping.exp: ftrace: tstart

remote_trace_start should probably start by making sure the remote
current thread matches inferior_ptid (calling set_general_thread), but
still, reducing unnecessary bouncing is a good idea.  It happens
because the memory/symbol/breakpoint routines use
switch_to_program_space_and_thread to do something in the right
context and then revert back to the previously current thread.

The fix is to simply make any_thread_of_process,
find_inferior_for_program_space, etc. give preference to the current
thread/inferior it if matches.

gdb/
2014-10-02  Pedro Alves  <palves@redhat.com>

* gdbthread.h (any_thread_of_process, any_live_thread_of_process):
Adjust comments.
* inferior.c (find_inferior_for_program_space): Give preference to
the current inferior.
* inferior.h (find_inferior_for_program_space): Update comment.
* progspace.c (switch_to_program_space_and_thread): Prefer the
current inferior if it's bound to the program space requested.  If
the inferior found doesn't have a PID yet, don't bother looking up
a thread.
* progspace.h (switch_to_program_space_and_thread): Adjust
comment.
* thread.c (any_thread_of_process, any_live_thread_of_process):
Give preference to the current thread.

10 years agodaily update
Alan Modra [Thu, 2 Oct 2014 00:00:37 +0000 (09:30 +0930)]
daily update

10 years agoReally fail inserting software breakpoints on read-only regions
Pedro Alves [Wed, 1 Oct 2014 22:31:55 +0000 (23:31 +0100)]
Really fail inserting software breakpoints on read-only regions

Currently, with "set breakpoint auto-hw off", we'll still try to
insert a software breakpoint at addresses covered by supposedly
read-only or inacessible regions:

 (top-gdb) mem 0x443000 0x450000 ro
 (top-gdb) set mem inaccessible-by-default off
 (top-gdb) disassemble
 Dump of assembler code for function main:
    0x0000000000443956 <+34>:    movq   $0x0,0x10(%rax)
 => 0x000000000044395e <+42>:    movq   $0x0,0x18(%rax)
    0x0000000000443966 <+50>:    mov    -0x24(%rbp),%eax
    0x0000000000443969 <+53>:    mov    %eax,-0x20(%rbp)
 End of assembler dump.
 (top-gdb) b *0x0000000000443969
 Breakpoint 5 at 0x443969: file ../../src/gdb/gdb.c, line 29.
 (top-gdb) c
 Continuing.
 warning: cannot set software breakpoint at readonly address 0x443969

 Breakpoint 5, 0x0000000000443969 in main (argc=1, argv=0x7fffffffd918) at ../../src/gdb/gdb.c:29
 29        args.argc = argc;
 (top-gdb)

We warn, saying that the insertion can't be done, but then proceed
attempting the insertion anyway, and in case of manually added
regions, the insert actually succeeds.

This is a regression; GDB used to fail inserting the breakpoint.  More
below.

I stumbled on this as I wrote a test that manually sets up a read-only
memory region with the "mem" command, in order to test GDB's behavior
with breakpoints set on read-only regions, even when the real memory
the breakpoints are set at isn't really read-only.  I wanted that in
order to add a test that exercises software single-stepping through
read-only regions.

Note that the memory regions that target_memory_map returns aren't
like e.g., what would expect to see in /proc/PID/maps on Linux.
Instead, they're the physical memory map from the _debuggers_
perspective.  E.g., a read-only region would be real ROM or flash
memory, while a read-only+execute mapping in /proc/PID/maps is still
read-write to the debugger (otherwise the debugger wouldn't be able to
set software breakpoints in the code segment).

If one tries to manually write to memory that falls within a memory
region that is known to be read-only, with e.g., "p foo = 1", then we
hit a check in memory_xfer_partial_1 before the write mananges to make
it to the target side.

But writing a software/memory breakpoint nowadays goes through
target_write_raw_memory, and unlike when writing memory with
TARGET_OBJECT_MEMORY, nothing on the TARGET_OBJECT_RAW_MEMORY path
checks whether we're trying to write to a read-only region.

At the time "breakpoint auto-hw" was added, we didn't have the
TARGET_OBJECT_MEMORY vs TARGET_OBJECT_RAW_MEMORY target object
distinction yet, and the code path in memory_xfer_partial that blocks
writes to read-only memory was hit for memory breakpoints too.  With
GDB 6.8 we had:

 warning: cannot set software breakpoint at readonly address 0000000000443943
 Warning:
 Cannot insert breakpoint 1.
 Error accessing memory address 0x443943: Input/output error.

So I started out by fixing this by adding the memory region validation
to TARGET_OBJECT_RAW_MEMORY too.

But later, when testing against GDBserver, I realized that that would
only block software/memory breakpoints GDB itself inserts with
gdb/mem-break.c.  If a target has a to_insert_breakpoint method, the
insertion request will still pass through to the target.  So I ended
up converting the "cannot set breakpoint" warning in breakpoint.c to a
real error return, thus blocking the insertion sooner.

With that, we'll end up no longer needing the TARGET_OBJECT_RAW_MEMORY
changes once software single-step breakpoints are converted to real
breakpoints.  We need them today as software single-step breakpoints
bypass insert_bp_location.  But, it'll be best to leave that in as
safeguard anyway, for other direct uses of TARGET_OBJECT_RAW_MEMORY.

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/
2014-10-01  Pedro Alves  <palves@redhat.com>

* breakpoint.c (insert_bp_location): Error out if inserting a
software breakpoint at a read-only address.
* target.c (memory_xfer_check_region): New function, factored out
from ...
(memory_xfer_partial_1): ... this.  Make the 'reg_len' local a
ULONGEST.
(target_xfer_partial) <TARGET_OBJECT_RAW_MEMORY>: Check the access
against the memory region attributes.

gdb/testsuite/
2014-10-01  Pedro Alves  <palves@redhat.com>

* gdb.base/breakpoint-in-ro-region.c: New file.
* gdb.base/breakpoint-in-ro-region.exp: New file.

10 years agoExit code of exited inferiors in -list-thread-groups
Simon Marchi [Mon, 29 Sep 2014 21:33:09 +0000 (17:33 -0400)]
Exit code of exited inferiors in -list-thread-groups

Don't reset the exit code at inferior exit and print it in
-list-thread-groups.

gdb/ChangeLog:

* NEWS: Announce new exit-code field in -list-thread-groups
output.
* inferior.c (exit_inferior_1): Don't clear exit code.
(inferior_appeared): Clear exit code.
* mi/mi-main.c (print_one_inferior): Add printing of the exit
code.

gdb/testsuite/ChangeLog:

* gdb.mi/mi-exit-code.exp: New file.
* gdb.mi/mi-exit-code.c: New file.

gdb/doc/ChangeLog:

* gdb.texinfo (Miscellaneous gdb/mi Commands): Document new
exit-code field in -list-thread-groups output.

10 years agoAdd read-only markers to generated gdb/regformats/ .dat files
Pedro Alves [Wed, 1 Oct 2014 12:40:13 +0000 (13:40 +0100)]
Add read-only markers to generated gdb/regformats/ .dat files

We have read-only markers in most generated sources already, so that
Emacs/Vi users won't edit them accidentally, but were missing them on
the generated gdb/regformats/ .dat files.

gdb/
2014-10-01  Pedro Alves  <palves@redhat.com>

* features/Makefile ($(outdir)/%.dat): Output "THIS FILE IS
GENERATED" along with emacs/vi read-only markers.
* regformats/aarch64.dat: Regenerate.
* regformats/arm-with-iwmmxt.dat: Regenerate.
* regformats/arm-with-neon.dat: Regenerate.
* regformats/arm-with-vfpv2.dat: Regenerate.
* regformats/arm-with-vfpv3.dat: Regenerate.
* regformats/i386/amd64-avx-linux.dat: Regenerate.
* regformats/i386/amd64-avx.dat: Regenerate.
* regformats/i386/amd64-avx512-linux.dat: Regenerate.
* regformats/i386/amd64-avx512.dat: Regenerate.
* regformats/i386/amd64-linux.dat: Regenerate.
* regformats/i386/amd64-mpx-linux.dat: Regenerate.
* regformats/i386/amd64-mpx.dat: Regenerate.
* regformats/i386/amd64.dat: Regenerate.
* regformats/i386/i386-avx-linux.dat: Regenerate.
* regformats/i386/i386-avx.dat: Regenerate.
* regformats/i386/i386-avx512-linux.dat: Regenerate.
* regformats/i386/i386-avx512.dat: Regenerate.
* regformats/i386/i386-linux.dat: Regenerate.
* regformats/i386/i386-mmx-linux.dat: Regenerate.
* regformats/i386/i386-mmx.dat: Regenerate.
* regformats/i386/i386-mpx-linux.dat: Regenerate.
* regformats/i386/i386-mpx.dat: Regenerate.
* regformats/i386/i386.dat: Regenerate.
* regformats/i386/x32-avx-linux.dat: Regenerate.
* regformats/i386/x32-avx.dat: Regenerate.
* regformats/i386/x32-avx512-linux.dat: Regenerate.
* regformats/i386/x32-avx512.dat: Regenerate.
* regformats/i386/x32-linux.dat: Regenerate.
* regformats/i386/x32.dat: Regenerate.
* regformats/microblaze-with-stack-protect.dat: Regenerate.
* regformats/mips-dsp-linux.dat: Regenerate.
* regformats/mips-linux.dat: Regenerate.
* regformats/mips64-dsp-linux.dat: Regenerate.
* regformats/mips64-linux.dat: Regenerate.
* regformats/nios2-linux.dat: Regenerate.
* regformats/rs6000/powerpc-32.dat: Regenerate.
* regformats/rs6000/powerpc-32l.dat: Regenerate.
* regformats/rs6000/powerpc-64l.dat: Regenerate.
* regformats/rs6000/powerpc-altivec32l.dat: Regenerate.
* regformats/rs6000/powerpc-altivec64l.dat: Regenerate.
* regformats/rs6000/powerpc-cell32l.dat: Regenerate.
* regformats/rs6000/powerpc-cell64l.dat: Regenerate.
* regformats/rs6000/powerpc-e500l.dat: Regenerate.
* regformats/rs6000/powerpc-vsx32l.dat: Regenerate.
* regformats/rs6000/powerpc-vsx64l.dat: Regenerate.
* regformats/s390-linux32.dat: Regenerate.
* regformats/s390-linux32v1.dat: Regenerate.
* regformats/s390-linux32v2.dat: Regenerate.
* regformats/s390-linux64.dat: Regenerate.
* regformats/s390-linux64v1.dat: Regenerate.
* regformats/s390-linux64v2.dat: Regenerate.
* regformats/s390-te-linux64.dat: Regenerate.
* regformats/s390x-linux64.dat: Regenerate.
* regformats/s390x-linux64v1.dat: Regenerate.
* regformats/s390x-linux64v2.dat: Regenerate.
* regformats/s390x-te-linux64.dat: Regenerate.
* regformats/tic6x-c62x-linux.dat: Regenerate.
* regformats/tic6x-c62x.dat: Regenerate.
* regformats/tic6x-c64x-linux.dat: Regenerate.
* regformats/tic6x-c64x.dat: Regenerate.
* regformats/tic6x-c64xp-linux.dat: Regenerate.
* regformats/tic6x-c64xp.dat: Regenerate.

10 years agofeatures/Makefile: Make 'make cfiles' default to generating all C files
Pedro Alves [Wed, 1 Oct 2014 10:18:22 +0000 (11:18 +0100)]
features/Makefile: Make 'make cfiles' default to generating all C files

This makes it easier to rebuild all GDB's generated target description
C files.

It also clarifies the comments a bit.  One might think we need a GDB
configured for the particular arquitecture (--target=foo).  But a
build that includes support for the target description is sufficient.
(GDB rejects target descriptions that explicitly specify the
architecture, with an <architecture> element, if the architecture is
unknown.)

Tested that "make clean-cfiles" deletes all .c files under
src/gdb/features/, and that "make cfiles" generates them all without
error, and that diffing the newly generated C files against master
comes out an empty diff.

gdb/
2014-10-01  Pedro Alves  <palves@redhat.com>

* features/Makefile: Update comments.
(XMLTOC): List all xml files we build C files from.
(clean-cfiles): New rule.

10 years agoRegenerate AVX512 target description C files
Pedro Alves [Wed, 1 Oct 2014 10:59:46 +0000 (11:59 +0100)]
Regenerate AVX512 target description C files

I regenerated all the .c files under src/gdb/features/ and this is
what I got.

gdb/
2014-10-01  Pedro Alves  <palves@redhat.com>

* features/i386/amd64-avx512-linux.c: Regenerate.
* features/i386/amd64-avx512.c: Regenerate.
* features/i386/x32-avx512-linux.c: Regenerate.
* features/i386/x32-avx512.c: Regenerate.

10 years agogdb/regformats: Don't build .dat files that aren't used by GDBserver
Pedro Alves [Wed, 1 Oct 2014 09:06:04 +0000 (10:06 +0100)]
gdb/regformats: Don't build .dat files that aren't used by GDBserver

The only reason .dat files exist is for GBBserver to use them in its
build system.

A few .dat files are listed as targets for generation that shouldn't.
The target descriptions these files are built from aren't used by
GDBserver.  They're fallback descriptions GDB itself has baked in.

Remove them from the list of .dat files to be generated, otherwise a
plain "make" under src/gdb/features/ generates new .dat files that
aren't even in the tree today.

gdb/
2014-10-01  Pedro Alves  <palves@redhat.com>

* features/Makefile (WHICH): Remove arm-with-m,
arm-with-m-fpa-layout and arm-with-m-vfp-d16.

10 years agofeatures/Makefile: Add a "clean" rule.
Pedro Alves [Wed, 1 Oct 2014 09:06:03 +0000 (10:06 +0100)]
features/Makefile: Add a "clean" rule.

So that we can do "make clean all" to regenerate all the renerated
.dat files.

gdb/
2014-10-01  Pedro Alves  <palves@redhat.com>

* features/Makefile (clean): New rule.

10 years agoFix features/i386/64bit-avx512.xml
Pedro Alves [Wed, 1 Oct 2014 09:06:04 +0000 (10:06 +0100)]
Fix features/i386/64bit-avx512.xml

This file's format is invalid, as it's missing some end quotes.

I noticed this because I tried to regenerate all the .dat files in
gdb/regformats/.  I got:

    sh ../../move-if-change ../regformats/i386/x32-avx.tmp ../regformats/i386/x32-avx.dat
    echo "# DO NOT EDIT: generated from i386/x32-avx512.xml" > ../regformats/i386/x32-avx512.tmp
    echo "name:`echo x32-avx512 | sed 's/-/_/g'`" >> ../regformats/i386/x32-avx512.tmp
    echo "xmltarget:x32-avx512.xml" >> ../regformats/i386/x32-avx512.tmp
    echo "expedite:rbp,rsp,rip" \
      >> ../regformats/i386/x32-avx512.tmp
    xsltproc --path "/home/pedro/gdb/mygit/src/gdb/features" --xinclude number-regs.xsl i386/x32-avx512.xml | \
      xsltproc sort-regs.xsl - | \
      xsltproc gdbserver-regs.xsl - >> ../regformats/i386/x32-avx512.tmp
    i386/64bit-avx512.xml:81: parser error : Unescaped '<' not allowed in attributes values
      <reg name="zmm11h" bitsize="256" type="v2ui128/>
      ^
    i386/64bit-avx512.xml:81: parser error : attributes construct error
      <reg name="zmm11h" bitsize="256" type="v2ui128/>
      ^
    i386/64bit-avx512.xml:81: parser error : Couldn't find end of Start Tag reg line 80
      <reg name="zmm11h" bitsize="256" type="v2ui128/>
      ^
    i386/64bit-avx512.xml:82: parser error : Unescaped '<' not allowed in attributes values
      <reg name="zmm12h" bitsize="256" type="v2ui128/>
      ^
    i386/64bit-avx512.xml:82: parser error : attributes construct error
      <reg name="zmm12h" bitsize="256" type="v2ui128/>
      ^
...
    i386/x32-avx512.xml:17: element include: XInclude error : could not load i386/64bit-avx512.xml, and no fallback was found
    -:1: parser error : Document is empty

    ^
    -:1: parser error : Start tag expected, '<' not found

    ^
    unable to parse -
    -:1: parser error : Document is empty

    ^
    -:1: parser error : Start tag expected, '<' not found

    ^
    unable to parse -
    make: *** [../regformats/i386/x32-avx512.dat] Error 6

Interestingly, gdb/expat manages to grok the broken file.

gdb/
2014-10-01  Pedro Alves  <palves@redhat.com>

* features/i386/64bit-avx512.xml (zmm10h, zmm11h, zmm12h, zmm13h)
(zmm14h): Add missing end quotes.

10 years agoAarch64: Make CPSR a 32-bit register again in the target description
Pedro Alves [Wed, 1 Oct 2014 09:06:45 +0000 (10:06 +0100)]
Aarch64: Make CPSR a 32-bit register again in the target description

This reverts commit a4d9ba85 - 'AARCH64: Change cpsr type to be
64bit.'.

Even though Linux's ptrace exposes CPSR as 64-bit, CPSR is really
32-bit, and basing GDB's fundamentals on a particular OS's ptrace(2)
implementation is a bad idea.

In addition, while that commit intended to fix big endian Aarch64, it
ended up breaking floating point debugging against GDBserver, for both
big and little endian, because it changed the CPSR to be 64-bit in the
features/aarch64-core.xml file, but missed regenerating the
regformats/aarch64.dat file.  If we generate it now, we see this:

  diff --git c/gdb/regformats/aarch64.dat w/gdb/regformats/aarch64.dat
  index afe1028..0d32183 100644
  --- c/gdb/regformats/aarch64.dat
  +++ w/gdb/regformats/aarch64.dat
  @@ -35,7 +35,7 @@ expedite:x29,sp,pc
   64:x30
   64:sp
   64:pc
  -32:cpsr
  +64:cpsr
   128:v0
   128:v1
   128:v2

IOW, that commit left regformats/aarch64.dat still considering CPSR as
32-bits.  regformats/aarch64.dat is used by GDBserver for its internal
regcache layout, and for the g/G packet register block.  See the
generated aarch64.c file in GDBserver's build dir.

So the target description xml file that GDBserver reports to GDB is
now claiming that CPSR is 64-bit, but what GDBserver actually puts in
the g/G register packets is 32-bits.  Because GDB thinks CPSR is
64-bit (because that's what the XML description says), GDB will be
reading the remaining 32-bit bits of CPSR out of v0 (the register
immediately afterwards), and then all the registers that follow CPSR
in the register packet end up wrong in GDB, because they're being read
from the wrong offsets...

gdb/
2014-10-01  Pedro Alves  <palves@redhat.com>

* features/aarch64-core.xml (cpsr): Change back to 32-bit.
* features/aarch64.c: Regenerate.

10 years agodaily update
Alan Modra [Wed, 1 Oct 2014 00:00:41 +0000 (09:30 +0930)]
daily update

10 years agoFix error from previous patch where tosize and tovalue were redefined
Cary Coutant [Tue, 30 Sep 2014 23:06:50 +0000 (16:06 -0700)]
Fix error from previous patch where tosize and tovalue were redefined
in a block, shadowing the declarations outside the block.

gold/
PR gold/17432
* resolve.cc (Symbol_table::resolve): Fix local shadowing error.

10 years agoFix SysV-style hash table when --hash-style=both.
Kito Cheng [Tue, 30 Sep 2014 21:36:46 +0000 (14:36 -0700)]
Fix SysV-style hash table when --hash-style=both.

When --hash-style-both is used, gold currently builds the sysv hash
table first, then the gnu hash table. Building the gnu hash table
renumbers the dynamic symbol table, invalidating the sysv hash
table. This patch reverses the order in which the hash tables are
build so that both hash tables are correct.

gold/
PR gold/13597
* layout.cc (Layout::create_dynamic_symtab): Build gnu-style
hash table before sysv-style hash table.

10 years agoRefactor native follow-fork.
Don Breazeal [Tue, 30 Sep 2014 18:01:57 +0000 (11:01 -0700)]
Refactor native follow-fork.

This patch reorganizes the code that implements follow-fork and
detach-on-fork in preparation for implementation of those features for the
extended-remote target.  The function linux-nat.c:linux_child_follow_fork
contained target-independent code mixed in with target-dependent code.  The
target-independent pieces need to be accessible for the host-side
implementation of follow-fork for extended-remote Linux targets.

The changes are fairly mechanical.  A new routine, follow_fork_inferior,
is implemented in infrun.c, containing those parts of
linux_child_follow_fork that manage inferiors and the inferior list.  The
parts of linux_child_follow_fork that deal with LWPs and target-specifics
were left in-place.  Although the order of some operations was changed, the
resulting functionality was not.

Modifications were made to the other native target follow-fork functions,
inf_ttrace_follow_fork and inf_ptrace_follow_fork, that should allow them
to work with follow_fork_inferior.  Some other adjustments were necessary
in inf-ttrace.c.  The changes to inf-ttrace.c and inf-ptrace.c were not
tested.

gdb/ChangeLog:

* inf-ptrace.c (inf_ptrace_follow_fork): Remove target-independent
code so as to work with follow_fork_inferior.
* inf-ttrace.c (inf_ttrace_follow_fork): Ditto.
(inf_ttrace_create_inferior): Remove reference to
inf_ttrace_vfork_ppid.
(inf_ttrace_attach): Ditto.
(inf_ttrace_detach): Ditto.
(inf_ttrace_kill): Use current_inferior instead of
inf_ttrace_vfork_ppid.
(inf_ttrace_wait): Eliminate use of inf_ttrace_vfork_ppid, report
TARGET_WAITKIND_VFORK_DONE event, delete HACK that switched the
inferior away from the parent.
* infrun.c (follow_fork): Call follow_fork_inferior instead of
target_follow_fork.
(follow_fork_inferior): New function.
(follow_inferior_reset_breakpoints): Make function static.
* infrun.h (follow_inferior_reset_breakpoints): Remove declaration.
* linux-nat.c (linux_child_follow_fork): Move target-independent
code to infrun.c:follow_fork_inferior.

10 years agoClean up after generated c files for MIPS DSP targets
James Hogan [Mon, 1 Sep 2014 09:19:31 +0000 (10:19 +0100)]
Clean up after generated c files for MIPS DSP targets

The gdbserver "clean" Makefile target wasn't removing the generated files
mips-dsp-linux.c and mips64-dsp-linux.c. Add rm commands to delete them.

gdb/gdbserver/ChangeLog:

* Makefile.in (clean): Add rm -f commands for mips-dsp-linux.c and
mips64-dsp-linux.c.

10 years agoDrop 'regset_from_core_section' gdbarch method
Andreas Arnez [Wed, 10 Sep 2014 12:55:39 +0000 (12:55 +0000)]
Drop 'regset_from_core_section' gdbarch method

Now that all instances of the regset_from_core_section gdbarch method
have been replaced by the new iterator method, delete the obsolete
method from the gdbarch interface.  Adjust all invocations and
references to it.

gdb/ChangeLog:

* gdbarch.sh (regset_from_core_section): Remove gdbarch method.
* gdbarch.c: Regenerate.
* gdbarch.h: Likewise.
* corelow.c (sniff_core_bfd): Drop presence check for deleted
gdbarch method 'regset_from_core_section'.
(get_core_register_section): Remove handling for the case that
regset == NULL and regset_from_core_section is defined.
(get_core_registers): Drop check for deleted method.
* procfs.c (procfs_do_thread_registers): Adjust comment.

10 years agoLinux targets: drop fall back to target method for 'make_corefile_notes'
Andreas Arnez [Wed, 10 Sep 2014 12:42:14 +0000 (12:42 +0000)]
Linux targets: drop fall back to target method for 'make_corefile_notes'

Now that all Linux targets use the regset iterator, the fall back to
the deprecated target method is dropped.

gdb/ChangeLog:

* linux-nat.c (linux_nat_collect_thread_registers): Remove.
(linux_nat_make_corefile_notes): Remove.
(linux_target_install_ops): Do not set target method
'make_corefile_notes'.
* linux-tdep.c (struct linux_corefile_thread_data)<collect>:
Remove field.
(linux_corefile_thread_callback): Instead of args->collect, call
linux_collect_thread_registers.
(linux_make_corefile_notes): Remove 'collect' parameter.  Return
NULL unless there is a regset iterator.
(linux_make_corefile_notes_1): Remove.
(linux_init_abi): Replace reference to linux_make_corefile_notes_1
by linux_make_corefile_notes.
* linux-tdep.h (linux_make_corefile_notes): Remove prototype.

10 years agoDrop target method 'fbsd_make_corefile_notes'
Andreas Arnez [Wed, 10 Sep 2014 12:02:43 +0000 (12:02 +0000)]
Drop target method 'fbsd_make_corefile_notes'

Now that all users of the target method 'fbsd_make_corefile_notes'
have been converted to the version in fbsd-tdep.c, the old method is
removed.

gdb/ChangeLog:

* fbsd-nat.c (find_signalled_thread, find_stop_signal)
(fbsd_collect_regset_section_cb, fbsd_make_corefile_notes):
Remove.
* fbsd-nat.h (fbsd_make_corefile_notes): Remove prototype.

10 years agoXTENSA: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Fri, 29 Nov 2013 17:06:22 +0000 (17:06 +0000)]
XTENSA: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For Xtensa targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* xtensa-tdep.c (xtensa_regset_from_core_section): Remove.
(xtensa_iterate_over_regset_sections): New.
(xtensa_gdbarch_init): Adjust gdbarch initialization.

10 years agoVAX: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Fri, 29 Nov 2013 17:06:09 +0000 (17:06 +0000)]
VAX: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For VAX targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* vax-tdep.c (vax_regset_from_core_section): Remove.
(vax_iterate_over_regset_sections): New.
(vax_gdbarch_init): Adjust gdbarch initialization.

10 years agoTILEGX: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Fri, 29 Nov 2013 17:05:44 +0000 (17:05 +0000)]
TILEGX: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For TILE-Gx GNU/Linux targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* tilegx-linux-tdep.c (TILEGX_LINUX_SIZEOF_GREGSET): New macro.
(tilegx_regset_from_core_section): Remove.
(tilegx_iterate_over_regset_sections): New.
(tilegx_linux_init_abi): Adjust gdbarch initialization.

10 years agoSPARC: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Fri, 29 Nov 2013 17:02:53 +0000 (17:02 +0000)]
SPARC: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For SPARC targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* sparc-tdep.c (sparc_regset_from_core_section): Remove.
(sparc_iterate_over_regset_sections): New.
(sparc32_gdbarch_init): Adjust gdbarch initialization.
* configure.tgt (gdb_target_obs): Add fbsd-tdep.o for SPARC FreeBSD
targets.
* sparc64fbsd-tdep.c (fbsd-tdep.h): Include.
(sparc64fbsd_init_abi): Call fbsd_init_abi.
* sparc64fbsd-nat.c (_initialize_sparc64fbsd_nat): Do not set
target method 'make_corefile_notes'.

10 years agoSH: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Fri, 29 Nov 2013 16:57:54 +0000 (16:57 +0000)]
SH: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For Super-H targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* sh-linux-tdep.c (sh_linux_init_abi): Set tdep fields
'sizeof_gregset' and 'sizeof_fpregset'.
* sh-tdep.c (sh_regset_from_core_section): Remove.
(sh_iterate_over_regset_sections): New.
(sh_gdbarch_init): Adjust gdbarch initialization.
* sh-tdep.h (struct gdbarch_tdep): New fields sizeof_gregset and
sizeof_fpregset.
* shnbsd-tdep.c (shnbsd_init_abi): Set tdep field
'sizeof_gregset'.

10 years agoSCORE: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Tue, 2 Sep 2014 14:34:34 +0000 (14:34 +0000)]
SCORE: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For S+core targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* score-tdep.c (score7_linux_regset_from_core_section): Remove.
(score7_linux_iterate_over_regset_sections): New.
(score_gdbarch_init): Adjust gdbarch initialization.

10 years agoPPC: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Wed, 10 Sep 2014 08:42:07 +0000 (08:42 +0000)]
PPC: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For PPC targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* configure.tgt (gdb_target_obs): Add fbsd-tdep.o for PowerPC
FreeBSD targets.
* ppcfbsd-nat.c (_initialize_ppcfbsd_nat): Do not set target
method 'make_corefile_notes'.
* ppcfbsd-tdep.c (fbsd-tdep.h): Include.
(ppcfbsd_regset_from_core_section): Remove.
(ppcfbsd_iterate_over_regset_sections): New.
(ppcfbsd_init_abi): Call fbsd_init_abi.  Adjust gdbarch
initialization.
* ppcnbsd-tdep.c (ppcnbsd_regset_from_core_section): Remove.
(ppcnbsd_iterate_over_regset_sections): New.
(ppcnbsd_init_abi): Adjust.
* ppcobsd-tdep.c (ppcobsd_regset_from_core_section): Remove.
(ppcobsd_iterate_over_regset_sections): New.
(ppcobsd_init_abi): Adjust.
* rs6000-aix-tdep.c (rs6000_aix_regset_from_core_section): Remove.
(rs6000_aix_iterate_over_regset_sections): New.
(rs6000_aix_init_osabi): Adjust.

10 years agoNIOS2: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Tue, 2 Sep 2014 14:00:44 +0000 (14:00 +0000)]
NIOS2: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For Nios II GNU/Linux targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* nios2-linux-tdep.c (NIOS2_GREGS_SIZE): New macro.
(nios2_regset_from_core_section): Remove.
(nios2_iterate_over_regset_sections): New.
(nios2_linux_init_abi): Adjust gdbarch initialization.

10 years agoMN10300: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'.
Andreas Arnez [Fri, 29 Nov 2013 16:51:36 +0000 (16:51 +0000)]
MN10300: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'.

For MN10300 GNU/Linux targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* mn10300-linux-tdep.c (am33_regset_from_core_section): Remove.
(am33_iterate_over_regset_sections): New.
(am33_linux_init_osabi): Adjust gdbarch initialization.

10 years agoMIPS: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Fri, 29 Nov 2013 16:49:03 +0000 (16:49 +0000)]
MIPS: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For MIPS targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* mips-linux-tdep.c (mips_linux_regset_from_core_section): Remove.
(mips_linux_iterate_over_regset_sections): New.
(mips_linux_init_abi): Adjust gdbarch initialization.
* mips64obsd-tdep.c (mips64obsd_regset_from_core_section): Remove.
(mips64obsd_iterate_over_regset_sections): New.
(mips64obsd_init_abi): Adjust.
* mipsnbsd-tdep.c (mipsnbsd_regset_from_core_section): Remove.
(mipsnbsd_iterate_over_regset_sections): New.
(mipsnbsd_init_abi): Adjust.

10 years agoM88K: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Fri, 29 Nov 2013 16:48:24 +0000 (16:48 +0000)]
M88K: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For M88K targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* m88k-tdep.c (m88k_regset_from_core_section): Remove.
(m88k_iterate_over_regset_sections): New.
(m88k_gdbarch_init): Adjust gdbarch initialization.

10 years agoIA64: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Sat, 29 Mar 2014 09:51:23 +0000 (09:51 +0000)]
IA64: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For IA-64 GNU/Linux targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* ia64-linux-tdep.c (ia64_linux_regset_from_core_section): Remove.
(ia64_linux_iterate_over_regset_sections): New.
(ia64_linux_init_abi): Adjust gdbarch initialization.

10 years agoM68K: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Sat, 29 Mar 2014 09:39:44 +0000 (09:39 +0000)]
M68K: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For m68k BSD and GNU/Linux targets, no longer define the gdbarch
method 'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* m68kbsd-tdep.c (m68kbsd_regset_from_core_section): Remove.
(m68kbsd_iterate_over_regset_sections): New.
(m68kbsd_init_abi): Adjust gdbarch initialization.
* m68klinux-tdep.c (m68k_linux_regset_from_core_section): Remove.
(m68k_linux_iterate_over_regset_sections): New.
(m68k_linux_init_abi): Adjust gdbarch initialization.

10 years agoM32R: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Fri, 29 Nov 2013 16:41:28 +0000 (16:41 +0000)]
M32R: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For m32r GNU/Linux targets, don't define the gdbarch method
'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* m32r-linux-tdep.c (M32R_LINUX_GREGS_SIZE): New macro.
(m32r_linux_regset_from_core_section): Remove.
(m32r_linux_iterate_over_regset_sections): New.
(m32r_linux_init_abi): Adjust gdbarch initialization.

10 years agoX86: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Sat, 29 Mar 2014 10:04:26 +0000 (10:04 +0000)]
X86: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For all I386 and AMD64 targets, replace all occurrences of
regset_from_core_section by the iterator method.

gdb/ChangeLog:

* amd64obsd-tdep.c (amd64obsd_regset_from_core_section): Remove.
(amd64obsd_iterate_over_regset_sections): New.
(amd64obsd_core_init_abi): Adjust gdbarch initialization.
* i386-cygwin-tdep.c (i386_windows_regset_from_core_section):
Remove.
(i386_cygwin_init_abi): Clear tdep->sizeof_fpregset.  Drop
regset_from_core_section initialization.
* i386-tdep.c (i386_regset_from_core_section): Remove.
(i386_iterate_over_regset_sections): New.
(i386_gdbarch_init): Adjust gdbarch initialization.
* i386-tdep.h (i386_regset_from_core_section): Remove prototype.
(i386_iterate_over_regset_sections): New prototype.
* i386obsd-tdep.c (i386obsd_aout_regset_from_core_section):
Remove.
(i386obsd_aout_iterate_over_regset_sections): New.
(i386obsd_aout_init_abi): Adjust gdbarch initialization.
* configure.tgt (gdb_target_obs): Add fbsd-tdep.o for all x86 FreeBSD
targets.
* amd64fbsd-tdep.c (fbsd-tdep.h): Include.
(amd64fbsd_init_abi): Call fbsd_init_abi.
* i386fbsd-tdep.c (fbsd-tdep.h): Include.
(i386fbsd4_init_abi): Call fbsd_init_abi.
* amd64fbsd-nat.c (_initialize_amd64fbsd_nat): No longer set
target method 'make_corefile_notes'.
* i386fbsd-nat.c (_initialize_i386fbsd_nat): Likewise.

10 years agoHPPA: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Sat, 29 Mar 2014 09:28:30 +0000 (09:28 +0000)]
HPPA: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For HP PA-RISC targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* hppa-hpux-tdep.c (hppa_hpux_regset_from_core_section): Remove.
(hppa_hpux_iterate_over_regset_sections): New.
(hppa_hpux_init_abi): Adjust gdbarch initialization.
* hppa-linux-tdep.c (hppa_linux_regset_from_core_section): Remove.
(hppa_linux_iterate_over_regset_sections): New.
(hppa_linux_init_abi): Adjust.
* hppanbsd-tdep.c (hppaobsd_regset_from_core_section): Remove.
(hppanbsd_iterate_over_regset_sections): New.
(hppanbsd_init_abi): Adjust.
* hppaobsd-tdep.c (hppaobsd_regset_from_core_section): Remove.
(hppaobsd_iterate_over_regset_sections): New.
(hppaobsd_init_abi): Adjust.

10 years agoFRV: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Fri, 29 Nov 2013 16:31:01 +0000 (16:31 +0000)]
FRV: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For FR-V GNU/Linux targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* frv-linux-tdep.c (frv_linux_regset_from_core_section): Remove.
(frv_linux_iterate_over_regset_sections): New.
(frv_linux_init_abi): Adjust gdbarch initialization.

10 years agoARM: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Sat, 29 Mar 2014 09:12:57 +0000 (09:12 +0000)]
ARM: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

For ARM BSD targets, don't define the gdbarch method
'regset_from_core_section', but the iterator method instead.

gdb/ChangeLog:

* arm-tdep.h (armbsd_regset_from_core_section): Remove prototype.
(armbsd_iterate_over_regset_sections): New prototype.
* armbsd-tdep.c (armbsd_regset_from_core_section): Remove.
(armbsd_iterate_over_regset_sections): New.
* armobsd-tdep.c (armobsd_init_abi): Adjust gdbarch
initialization.

10 years agoALPHA: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Mon, 3 Mar 2014 13:54:50 +0000 (13:54 +0000)]
ALPHA: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

Don't define the 'regset_from_core_section' method, but the iterator
method instead.  Do this for GNU/Linux- as well as
Net/OpenBSD-targets.  In the case of GNU/Linux this should enable
non-native use of the 'generate-core-file' command.

gdb/ChangeLog:

* alpha-linux-tdep.c (alpha_linux_regset_from_core_section): Remove.
(alpha_linux_iterate_over_regset_sections): New.
(alpha_linux_init_abi): Adjust gdbarch initialization.
* alphabsd-tdep.h (alphanbsd_regset_from_core_section): Remove
prototype.
(alphanbsd_iterate_over_regset_sections): New prototype.
     * alphafbsd-tdep.c (alphafbsd_init_abi): Add comment for missing
     fbsd_init_abi invocation.
* alphanbsd-tdep.c (alphanbsd_supply_gregset): Move below
alphanbsd_aout_supply_gregset.  Invoke the latter for the
appropriate size.
(alphanbsd_aout_gregset): Remove.
(alphanbsd_regset_from_core_section): Remove.
(alphanbsd_iterate_over_regset_sections): New.
(alphanbsd_init_abi): Adjust gdbarch initialization.
* alphaobsd-tdep.c (alphaobsd_init_abi): Likewise.

10 years agoAARCH64: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'
Andreas Arnez [Mon, 28 Apr 2014 07:56:51 +0000 (07:56 +0000)]
AARCH64: Migrate from 'regset_from_core_section' to 'iterate_over_regset_sections'

Don't define the 'regset_from_core_section' method, but the iterator
method instead.  This slightly reduces the code and enables non-native
use of the 'generate-core-file' command.

Also, when all instances of 'regset_from_core_section' are replaced,
it can be dropped from the gdbarch interface.

gdb/ChangeLog:

* aarch64-linux-tdep.c (aarch64_linux_regset_from_core_section):
Remove.
(aarch64_linux_iterate_over_regset_sections): New.
(aarch64_linux_init_abi): Adjust gdbarch initialization.

10 years agoAdd multi-arch capable 'fbsd_make_corefile_notes' variant
Andreas Arnez [Tue, 3 Dec 2013 11:35:35 +0000 (11:35 +0000)]
Add multi-arch capable 'fbsd_make_corefile_notes' variant

This creates a new version of the FreeBSD core file note generation
logic in the new target-dependent file "fbsd-tdep.c".  The new version
is mostly copied from "fbsd-nat.c", but uses the iterator instead of
regset_from_core_section and defines fbsd_make_corefile_notes as a
gdbarch method instead of a target method.

Consecutive architecture-dependent changes exploit the new version,
migrating away from the target method.  When all FreeBSD targets are
changed, the target method can go away.

gdb/ChangeLog:

* fbsd-tdep.c: New file.
* fbsd-tdep.h: New file.
* Makefile.in (ALL_TARGET_OBS): Add fbsd-tdep.o.
(HFILES_NO_SRCDIR): Add fbsd-tdep.h.
(ALLDEPFILES): Add fbsd-tdep.c.

10 years agoAdd 'regset' parameter to 'iterate_over_regset_sections_cb'
Andreas Arnez [Fri, 12 Sep 2014 08:42:48 +0000 (08:42 +0000)]
Add 'regset' parameter to 'iterate_over_regset_sections_cb'

This adds the 'regset' parameter to the iterator callback.
Consequently the 'regset_from_core_section' method is dropped for all
targets that provide the iterator method.

This change prepares for replacing regset_from_core_section
everywhere, thereby eliminating one gdbarch interface.  Since the
iterator is usually no more complex than regset_from_core_section
alone, targets that previously didn't define core_regset_sections will
then gain multi-arch capable core file generation support without
increased complexity.

gdb/ChangeLog:

* gdbarch.sh (iterate_over_regset_sections_cb): Add regset
parameter.
* gdbarch.h: Regenerate.
* corelow.c (sniff_core_bfd): Don't sniff if gdbarch has a regset
iterator.
(get_core_register_section): Add parameter 'regset' and use it, if
set.  Add parameter 'min_size' and verify the bfd section size
against it.
(get_core_registers_cb): Add parameter 'regset' and pass it to
get_core_register section.  For the "standard" register sections
".reg" and ".reg2", set an appropriate default for human_name.
(get_core_registers): Don't abort when the gdbarch has an iterator
but no regset_from_core_section.  Add NULL/0 for parameters
'regset'/'min_size' in calls to get_core_register_section.
* linux-tdep.c (linux_collect_regset_section_cb): Add parameter
'regset' and use it instead of calling the
regset_from_core_section gdbarch method.
* i386-tdep.h (struct gdbarch_tdep): Add field 'fpregset'.
* i386-tdep.c (i386_supply_xstateregset)
(i386_collect_xstateregset, i386_xstateregset): Moved to
i386-linux-tdep.c.
(i386_regset_from_core_section): Drop handling for .reg-xfp and
.reg-xstate.
(i386_gdbarch_init): Set tdep field 'fpregset'.  Enable generic
core file support only if the regset iterator hasn't been set.
* i386-linux-tdep.c (i386_linux_supply_xstateregset)
(i386_linux_collect_xstateregset, i386_linux_xstateregset): New.
Moved from i386-tdep.c and renamed to *_linux*.
(i386_linux_iterate_over_regset_sections): Add regset parameter to
each callback invocation.  Allow any .reg-xstate size when reading
from a core file.
* amd64-tdep.c (amd64_supply_xstateregset)
(amd64_collect_xstateregset, amd64_xstateregset): Moved to
amd64-linux-tdep.c.
(amd64_regset_from_core_section): Remove.
(amd64_init_abi): Set new tdep field 'fpregset'.  No longer
install an amd64-specific regset_from_core_section gdbarch method.
* amd64-linux-tdep.c (amd64_linux_supply_xstateregset)
(amd64_linux_collect_xstateregset, amd64_linux_xstateregset): New.
Moved from amd64-tdep.c and renamed to *_linux*.
(amd64_linux_iterate_over_regset_sections): Add regset parameter
to each callback invocation.  Allow any .reg-xstate size when
reading from a core file.
* arm-linux-tdep.c (arm_linux_regset_from_core_section): Remove.
(arm_linux_iterate_over_regset_sections): Add regset parameter to
each callback invocation.
(arm_linux_init_abi): No longer set the regset_from_core_section
gdbarch method.
* ppc-linux-tdep.c (ppc_linux_regset_from_core_section): Remove.
(ppc_linux_iterate_over_regset_sections): Add regset parameter to
each callback invocation.
(ppc_linux_init_abi): No longer set the regset_from_core_section
gdbarch method.
* s390-linux-tdep.c (struct gdbarch_tdep): Remove the fields
gregset, sizeof_gregset, fpregset, and sizeof_fpregset.
(s390_regset_from_core_section): Remove.
(s390_iterate_over_regset_sections): Add regset parameter to each
callback invocation.
(s390_gdbarch_init): No longer set the regset_from_core_section
gdbarch method.  Drop initialization of deleted tdep fields.

10 years agoReplace 'core_regset_sections' by iterator method
Andreas Arnez [Thu, 4 Sep 2014 15:26:43 +0000 (15:26 +0000)]
Replace 'core_regset_sections' by iterator method

The core_regset_sections list in gdbarch (needed for multi-arch
capable core file generation support) is replaced by an iterator
method.  Overall, this reduces the code a bit, and it allows for more
flexibility.

gdb/ChangeLog:

* amd64-linux-tdep.c (amd64_linux_regset_sections): Remove.
(amd64_linux_iterate_over_regset_sections): New.
(amd64_linux_init_abi_common): Don't install the regset section
list, but the new iterator in gdbarch.
* arm-linux-tdep.c (arm_linux_fpa_regset_sections)
(arm_linux_vfp_regset_sections): Remove.  Move combined logic...
(arm_linux_iterate_over_regset_sections): ...here.  New function.
(arm_linux_init_abi): Set iterator instead of section list.
* corelow.c (get_core_registers_cb): New function, logic moved
from...
(get_core_registers): ...loop body here.  Use new iterator method
instead of walking through the regset section list.
* gdbarch.sh: Remove 'core_regset_sections'.  New method
'iterate_over_regset_sections'.  New typedef
'iterate_over_regset_sections_cb'.
* gdbarch.c: Regenerate.
* gdbarch.h: Likewise.
* i386-linux-tdep.c (i386_linux_regset_sections)
(i386_linux_sse_regset_sections, i386_linux_avx_regset_sections):
Remove.
(i386_linux_iterate_over_regset_sections): New.
(i386_linux_init_abi): Don't choose a regset section list, but
install new iterator in gdbarch.
* linux-tdep.c (struct linux_collect_regset_section_cb_data): New.
(linux_collect_regset_section_cb): New function, logic moved
from...
(linux_collect_thread_registers): ...loop body here.  Use iterator
method instead of walking through list.
(linux_make_corefile_notes_1): Check for presence of iterator
method instead of regset section list.
* ppc-linux-tdep.c (ppc_linux_vsx_regset_sections)
(ppc_linux_vmx_regset_sections, ppc_linux_fp_regset_sections)
(ppc64_linux_vsx_regset_sections, ppc64_linux_vmx_regset_sections)
(ppc64_linux_fp_regset_sections): Remove.  Move combined logic...
(ppc_linux_iterate_over_regset_sections): ...here.  New function.
(ppc_linux_init_abi): Don't choose from above regset section
lists, but install new iterator in gdbarch.
* regset.h (struct core_regset_section): Remove.
* s390-linux-tdep.c (struct gdbarch_tdep): Add new fields
have_linux_v1, have_linux_v2, and have_tdb.
(s390_linux32_regset_sections, s390_linux32v1_regset_sections)
(s390_linux32v2_regset_sections, s390_linux64_regset_sections)
(s390_linux64v1_regset_sections, s390_linux64v2_regset_sections)
(s390x_linux64_regset_sections, s390x_linux64v1_regset_sections)
(s390x_linux64v2_regset_sections): Remove.  Move combined logic...
(s390_iterate_over_regset_sections): ...here.  New function.  Use
new tdep fields.
(s390_gdbarch_init): Set new tdep fields.  Don't choose from above
regset section lists, but install new iterator.

10 years agoError in build_executable_own_libs for non-native target
Yao Qi [Sun, 28 Sep 2014 03:43:46 +0000 (11:43 +0800)]
Error in build_executable_own_libs for non-native target

gdb/testsuite:

2014-09-30  Yao Qi  <yao@codesourcery.com>

* lib/prelink-support.exp (build_executable_own_libs): Error if
the target isn't native.

10 years agoSkip dlopen-libpthread.exp in cross testing
Yao Qi [Thu, 25 Sep 2014 07:50:07 +0000 (15:50 +0800)]
Skip dlopen-libpthread.exp in cross testing

I see the following fails on arm-linux-gnueabi,

result of ldd build-git/arm/gdb/testsuite/gdb.threads/dlopen-libpthread.so is 1
output of ldd build-git/arm/gdb/testsuite/gdb.threads/dlopen-libpthread.so is not a dynamic executable
child process exited abnormally
FAIL: gdb.threads/dlopen-libpthread.exp: ldd dlopen-libpthread.so
FAIL: gdb.threads/dlopen-libpthread.exp: ldd dlopen-libpthread.so output contains libs

the test script invokes ldd (on host) for the target libraries, which
is wrong.  ldd can't be cross because it invokes dynamic linker with
LD_TRACE_LOADED_OBJECTS and gets the dependent libraries.  My first
reaction to this problem is to execute ld.so on the target (like
remote_exec target).  When I start to hack proc build_executable_own_libs,
I find it has assumptions here and there that the native testing is
performed.  Then I check the callers of build_executable_own_libs,
and they are all skipped if isnative is false.  It is reasonable to do
the same in dlopen-libpthread.exp too.

gdb/testsuite:

2014-09-30  Yao Qi  <yao@codesourcery.com>

* gdb.threads/dlopen-libpthread.exp: Skip it if isnative is
false.

10 years ago2014-09-29 Sriraman Tallam <tmsriram@google.com>
Sriraman Tallam [Tue, 30 Sep 2014 00:30:54 +0000 (17:30 -0700)]
2014-09-29  Sriraman Tallam  <tmsriram@google.com>

* options.h (--pic-executable): Add negative to alias to -no-pie.

10 years agodaily update
Alan Modra [Tue, 30 Sep 2014 00:00:35 +0000 (09:30 +0930)]
daily update

10 years agoFix library-list.dtd -> library-list-svr4.dtd
Jan Kratochvil [Mon, 29 Sep 2014 15:38:12 +0000 (17:38 +0200)]
Fix library-list.dtd -> library-list-svr4.dtd

commit 2268b414f486239cbcc0f756f157c3e03599efac
added file "features/library-list-svr4.dtd" but the added code uses
"library-list.dtd" instead.

Curiously after changing for a test s/name/nXme/ in the DTD making the
gdbserver output non-conforming there is no warning or regression seen (tested
gdb.base/shlib-call.exp, using_xfer is still 1).  I did not check more why the
DTD conformance verification does not work.

gdb/ChangeLog
2014-09-29  Jan Kratochvil  <jan.kratochvil@redhat.com>

* solib-svr4.c (svr4_parse_libraries): Use "library-list-svr4.dtd".

10 years agoFix build for OLD_FREEBSD_ABI_LABEL
H.J. Lu [Mon, 29 Sep 2014 15:35:49 +0000 (08:35 -0700)]
Fix build for OLD_FREEBSD_ABI_LABEL

PR ld/17440
* elf32-i386.c (elf_i386_fbsd_post_process_headers): Fix build
for OLD_FREEBSD_ABI_LABEL.

10 years ago2014-09-29 Terry Guo <terry.guo@arm.com>
Terry Guo [Mon, 29 Sep 2014 02:12:10 +0000 (10:12 +0800)]
2014-09-29  Terry Guo  <terry.guo@arm.com>

        * as.c (create_obj_attrs_section): Move it and call it from ...
        * write.c (create_obj_attrs_section): ... here.
        (subsegs_finish_section): Refactored.

10 years agodaily update
Alan Modra [Mon, 29 Sep 2014 00:00:35 +0000 (09:30 +0930)]
daily update

10 years agodaily update
Alan Modra [Sun, 28 Sep 2014 00:00:52 +0000 (09:30 +0930)]
daily update

10 years agoDo away with hash table line lookup in dwarf2dbg.c
Alan Modra [Sat, 27 Sep 2014 02:54:32 +0000 (12:24 +0930)]
Do away with hash table line lookup in dwarf2dbg.c

Hash lookup is silly when we can attach the line table info directly
to sections instead.  Worse, hash lookup fails when we have multiple
sections with the same name.

gas/
* dwarf2dbg.c (all_segs_hash): Delete.
(get_line_subseg): Delete last_seg, last_subseg, last_line_subseg.
Retrieve line_seg for section via seg_info.
* subsegs.h (segment_info_typet): Add dwarf2_line_seg.
gas/testsuite/
* gas/elf/group2.d, * gas/elf/group2.s: New test.
* gas/elf/elf.exp: Run it.

10 years agodaily update
Alan Modra [Sat, 27 Sep 2014 00:00:35 +0000 (09:30 +0930)]
daily update

10 years agoFix handling of relocations against TLS section symbols.
Cary Coutant [Fri, 26 Sep 2014 20:34:27 +0000 (13:34 -0700)]
Fix handling of relocations against TLS section symbols.

Gold doesn't handle relocations against the section symbol for a TLS
section correctly. Instead of using the offset of the section relative
to the TLS segment, it uses the address of the actual section.  This
patch checks for section symbols for TLS sections, and treats them
the same as TLS symbols.

gold/
PR gold/16773
* object.cc (Sized_relobj_file): Compute value of section symbols
for TLS sections the same as TLS symbols.

10 years agoDon't prune program spaces when doing "maintenance info program-spaces"
Simon Marchi [Fri, 26 Sep 2014 14:35:12 +0000 (10:35 -0400)]
Don't prune program spaces when doing "maintenance info program-spaces"

Remove the pruning of program spaces in print_program_space to remove
unwanted side-effects. "info" commands and print routines should
generally not change the state of the debugger.

gdb/Changelog:

* progspace.c (print_program_space): Don't prune program spaces
before printing them.

10 years agoFix problem where TLS common symbols are not allocated properly during LTO.
Cary Coutant [Fri, 26 Sep 2014 04:47:10 +0000 (21:47 -0700)]
Fix problem where TLS common symbols are not allocated properly during LTO.

The plugin API doesn't provide a way for the claimed file handler to
identify a TLS symbol, so when adding a common TLS symbol, gold
mistakenly places the symbol in the non-TLS commons list, and does
not override it when we see the replacement symbol that is marked
as TLS. Consequently, we allocate the TLS common symbol as a regular
common, and, if it's the only TLS in the program, we'll give an
internal error because we haven't allocated a TLS segment.

This patch fixes the problem by removing an exclusion where common
symbols would not override the placeholder symbols, but checking to
see if the size needs adjusting (the original reason for the exclusion).
Furthermore, we need to avoid putting placeholder symbols in the common
list, and wait until we see a real common symbol with a type we can
trust.

gold/
PR gold/17432
* resolve.cc (Symbol_table::resolve): Override common placeholder
symbols, but adjust sizes.
* symtab.cc (Symbol_table::add_from_object): Don't add placeholder
symbols to common lists.

10 years agodaily update
Alan Modra [Fri, 26 Sep 2014 00:00:35 +0000 (09:30 +0930)]
daily update

10 years agoinfrun.c:user_visible_resume_ptid: Don't check singlestep_breakpoints_inserted_p
Pedro Alves [Mon, 22 Sep 2014 10:12:30 +0000 (11:12 +0100)]
infrun.c:user_visible_resume_ptid: Don't check singlestep_breakpoints_inserted_p

What matters for this function, is whether the user requested a
"step", for "set scheduler-locking step", not whether GDB is doing an
internal step for some reason.

 /* Return a ptid representing the set of threads that we will proceed,
    in the perspective of the user/frontend.  */
 extern ptid_t user_visible_resume_ptid (int step);

Therefore, the check for singlestep_breakpoints_inserted_p is actually
incorrect, and we end up applying schedlock more often on sss targets
than on non-sss targets.

Found by inspection while working on a patch that eliminates the
singlestep_breakpoints_inserted_p global.

Tested on x86_64 Fedora 20 on top of my 'software single-step on x86'
series.

gdb/
2014-09-25  Pedro Alves  <palves@redhat.com>

* infrun.c (user_visible_resume_ptid): Don't check
singlestep_breakpoints_inserted_p.

10 years agobreakpoint.c: debug output when we skip inserting a breakpoint
Pedro Alves [Mon, 22 Sep 2014 13:11:53 +0000 (14:11 +0100)]
breakpoint.c: debug output when we skip inserting a breakpoint

gdb/
2014-09-25  Pedro Alves  <palves@redhat.com>

* breakpoint.c (should_be_inserted): Add debug output.

10 years agoinfrun.c: comment/typo fixes
Pedro Alves [Thu, 25 Sep 2014 15:31:04 +0000 (16:31 +0100)]
infrun.c: comment/typo fixes

gdb/
2014-09-25  Pedro Alves  <palves@redhat.com>

* infrun.c (stepping_past_instruction_at)
(clear_exit_convenience_vars): Point at infrun.h instead of
inferior.h.
(handle_signal_stop): Fix typo.

10 years agodaily update
Alan Modra [Thu, 25 Sep 2014 00:00:40 +0000 (09:30 +0930)]
daily update

10 years agoFix typo in thumb_in_function_epilogue_p
Yao Qi [Fri, 19 Sep 2014 08:37:07 +0000 (16:37 +0800)]
Fix typo in thumb_in_function_epilogue_p

This patch fixes a typo in the bit mask I've made in my previous code
refactor.  If PC is in the register list, the bit 8 is one, so bit
mask 0xff00 should be used.  Current condition is a constant false.

gdb:

2014-09-24  Yao Qi  <yao@codesourcery.com>

* arm-tdep.c (thumb_in_function_epilogue_p): Fix typo in the
bitmask.

10 years agoRegen gold POTFILES.in
Alan Modra [Wed, 24 Sep 2014 08:36:58 +0000 (18:06 +0930)]
Regen gold POTFILES.in

* po/POTFILES.in: Regenerate.

10 years agoBFD: Add support for more than one plugin in lib/bfd-plugins
Markus Trippelsdorf [Wed, 24 Sep 2014 08:34:53 +0000 (18:04 +0930)]
BFD: Add support for more than one plugin in lib/bfd-plugins

ar, nm and ranlib currently lack the ability to handle more than one
plugin in lib/bfd-plugins. This patch reshuffles the logic in plugin.c
to add this functionality. One can now place both llvm and gcc plugins
in this directory and have them loaded automatically.
Mixed gcc/llvm archives are also supported (but not very useful until
ld.bfd and ld.gold also would load multiple plugins and use them to
claim different object files).

PR 17422
* plugin.c (try_claim): New function. Moved from
bfd_plugin_object_p.
(try_load_plugin): Pass through bfd. Add test.
(load_plugin): Pass through bfd.
(bfd_plugin_object_p): Move logic to try_claim.

10 years agoAdd PR reference to ChangeLog entry.
Cary Coutant [Wed, 24 Sep 2014 06:35:36 +0000 (23:35 -0700)]
Add PR reference to ChangeLog entry.

2014-09-23  Taiju Tsuiki  <tzik@google.com>
            Cary Coutant  <ccoutant@google.com>

gold/
PR gold/14860
* gold.cc (queue_final_tasks): Add Write_sections_task as a blocker
on input_sections_blocker.
* layout.cc (Write_sections_task::locks): Unblock
input_sections_blocker_.
* layout.h (Write_sections_task::Write_sections_task): Add
input_sections_blocker.
* testsuite/Makefile.am (exception_x86_64_bnd_test): Add gcctestdir/ld
to DEPENDENCIES.
* testsuite/Makefile.in: Regenerate.

10 years agoFix race condition causing assert in Eh_frame_hdr::do_sized_write().
Cary Coutant [Wed, 24 Sep 2014 06:18:19 +0000 (23:18 -0700)]
Fix race condition causing assert in Eh_frame_hdr::do_sized_write().

2014-09-23  Taiju Tsuiki  <tzik@google.com>
            Cary Coutant  <ccoutant@google.com>

gold/
* gold.cc (queue_final_tasks): Add Write_sections_task as a blocker
on input_sections_blocker.
* layout.cc (Write_sections_task::locks): Unblock
input_sections_blocker_.
* layout.h (Write_sections_task::Write_sections_task): Add
input_sections_blocker.
* testsuite/Makefile.am (exception_x86_64_bnd_test): Add gcctestdir/ld
to DEPENDENCIES.
* testsuite/Makefile.in: Regenerate.

10 years agodaily update
Alan Modra [Wed, 24 Sep 2014 00:00:52 +0000 (09:30 +0930)]
daily update

10 years agoDisallow VEX/EVEX encoded instructions in 16-bit mode
H.J. Lu [Tue, 23 Sep 2014 18:12:23 +0000 (11:12 -0700)]
Disallow VEX/EVEX encoded instructions in 16-bit mode

gas/

PR gas/17421
* config/tc-i386.c (md_assemble): Disallow VEX/EVEX encoded
instructions in 16-bit mode.

gas/testsuite/

PR gas/17421
* gas/i386/i386.exp: Run inval-16.

* gas/i386/inval-16.l: New file.
* gas/i386/inval-16.s: Likewise.

10 years agoHonour SIGILL and SIGSEGV in cancel breakpoint and event lwp selection
Yao Qi [Fri, 12 Sep 2014 05:35:11 +0000 (13:35 +0800)]
Honour SIGILL and SIGSEGV in cancel breakpoint and event lwp selection

I see the following fail on arm-none-linux-gnueabi testing,

(gdb) continue^M
Continuing.^M
^M
Program received signal SIGILL, Illegal instruction.^M
[Switching to Thread 1003]^M
handler (signo=10) at
/scratch/yqi/arm-none-linux-gnueabi/src/gdb-trunk/gdb/testsuite/gdb.threads/sigstep-threads.c:33^M
33        tgkill (getpid (), gettid (), SIGUSR1);       /* step-2 */^M
(gdb) FAIL: gdb.threads/sigstep-threads.exp: continue

the cause is that GDBserver doesn't cancel the breakpoint if the stop
signal is SIGILL.  The kernel used here is a little old, 2.6.x, and
doesn't translate SIGILL to SIGTRAP when program hits breakpoint
instruction (which is an illegal instruction actually).  GDB and
GDBserver can translate SIGILL to SIGTRAP under certain circumstance,
so it is not a problem here.  See gdbserver/linux-low.c:linux_wait_1

  /* If this event was not handled before, and is not a SIGTRAP, we
     report it.  SIGILL and SIGSEGV are also treated as traps in case
     a breakpoint is inserted at the current PC.  If this target does
     not support internal breakpoints at all, we also report the
     SIGTRAP without further processing; it's of no concern to us.  */
  maybe_internal_trap
    = (supports_breakpoints ()
       && (WSTOPSIG (w) == SIGTRAP
   || ((WSTOPSIG (w) == SIGILL
|| WSTOPSIG (w) == SIGSEGV)
       && (*the_low_target.breakpoint_at) (event_child->stop_pc))));

However, SIGILL and SIGSEGV is not considered when cancelling
breakpoint, which causes the fail above.  That is, when GDB is doing
software single step on address ADDR, both thread A and thread B hits the
software single step breakpoint, and get SIGILL.  GDB selects the event
from thread A, removes the software single step breakpoint, and resume
the program.  The event (SIGILL) from thread B is reported to GDB, but
GDB doesn't regard this SIGILL as SIGTRAP, because the breakpoint on
address ADDR was removed, so GDB reports "Program received signal
SIGILL".

The patch is to allow calling cancel_breakpoint if the signal is
SIGILL and SIGSEGV.  This patch fixes the fail above.  Likewise, event
lwp selection should honour SIGILL and SIGSEGV too.

gdb/gdbserver:

2014-09-23  Yao Qi  <yao@codesourcery.com>

* linux-low.c (lp_status_maybe_breakpoint): New function.
(linux_low_filter_event): Call lp_status_maybe_breakpoint.
(count_events_callback): Likewise.
(select_event_lwp_callback): Likewise.
(cancel_breakpoints_callback): Likewise.

10 years agodaily update
Alan Modra [Tue, 23 Sep 2014 00:00:37 +0000 (09:30 +0930)]
daily update

10 years agoFix 'call8: call target out of range' xtensa ld relaxation bug
Sterling Augustine [Tue, 25 Jan 2011 21:59:13 +0000 (13:59 -0800)]
Fix 'call8: call target out of range' xtensa ld relaxation bug

During link-time relaxation distance between cross-section call site and
its target may grow, producing 'call target out of range' error for
relaxed calls. Be more conservative when calculating whether or not a
callx can be converted to a straight call.

2014-09-23  Sterling Augustine  <augustine.sterling@gmail.com>

bfd/
    * elf32-xtensa.c (is_resolvable_asm_expansion): for cross-section
    call relaxation use furthermost addresses where call source and
    destination can be to check whether it's in the range of a direct
    call.

10 years agoIgnore MOD field for control/debug register move
H.J. Lu [Mon, 22 Sep 2014 16:38:53 +0000 (09:38 -0700)]
Ignore MOD field for control/debug register move

This patch ignores the MOD field in control/debug register move
instructions.

gas/testsuite/

* gas/i386/cdr.d: New file.
* gas/i386/cdr.s: Likewise.
* gas/i386/x86-64-cdr.d: Likewise.

* gas/i386/i386.exp: Run cdr and x86-64-cdr.

opcodes/

* i386-dis.c (MOD_0F20): Removed.
(MOD_0F21): Likewise.
(MOD_0F22): Likewise.
(MOD_0F23): Likewise.
(dis386_twobyte): Replace MOD_0F20, MOD_0F21, MOD_0F22 and
MOD_0F23 with "movZ".
(mod_table): Remove MOD_0F20, MOD_0F21, MOD_0F22 and MOD_0F23.
(OP_R): Check mod/rm byte and call OP_E_register.

10 years agoreadline/search.c: Remove useless parameter '0' for rl_message()
Chen Gang [Sat, 20 Sep 2014 03:50:14 +0000 (11:50 +0800)]
readline/search.c: Remove useless parameter '0' for rl_message()

The related warning under Darwin x86_64:

  gcc -c -DHAVE_CONFIG_H    -I. -I../../binutils-gdb/readline -DRL_LIBRARY_VERSION='"6.2"' -g -O2 ../../binutils-gdb/readline/search.c
  ../../binutils-gdb/readline/search.c:213:24: warning: data argument not used by format string [-Wformat-extra-args]
    rl_message ("%s", p, 0);
                ~~~~     ^
  1 warning generated.

readline/ChangeLog.gdb:

* search.c (_rl_nsearch_init): Remove useless parameter '0' for
rl_message().

Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
10 years ago2014-09-22 Jan-Benedict Glaw <jbglaw@lug-owl.de>
Jan-Benedict Glaw [Mon, 22 Sep 2014 11:02:10 +0000 (13:02 +0200)]
2014-09-22  Jan-Benedict Glaw  <jbglaw@lug-owl.de>

* gdb.texinfo (Set Breaks): Add missing "@end table".

10 years agoUpdate target_stop's documentation
Gary Benson [Mon, 22 Sep 2014 10:33:59 +0000 (11:33 +0100)]
Update target_stop's documentation

This commit updates target_stop's documentation to clarify that
it is asynchronous.

gdb/ChangeLog:

* target.c (target_stop): Updated comment.

10 years agoRename target_{stop,continue}_ptid
Gary Benson [Mon, 22 Sep 2014 10:33:59 +0000 (11:33 +0100)]
Rename target_{stop,continue}_ptid

This commit renames target_stop_ptid as target_stop_and_wait and
target_continue_ptid as target_continue_no_signal.  Comments are
updated to more fully describe the functions' behaviour.

gdb/ChangeLog:

* target/target.h (target_stop_ptid): Renamed as...
(target_stop_and_wait): New function.  Updated comment.
All uses updated.
(target_continue_ptid): Renamed as...
(target_continue_no_signal): New function.  Updated comment.
All uses updated.

10 years agoFind lto plugin when using gcc-5.0
Alan Modra [Mon, 22 Sep 2014 08:44:27 +0000 (18:14 +0930)]
Find lto plugin when using gcc-5.0

I originally had this as --print-prog-name and changed back to
--print-file-name to suit older gcc, neglecting to check whether
gcc-5.0 --print-file-name finds the lto plugin.  It doesn't.

* ld-plugin/lto.exp: Use both --print-file-name and --print-prog-name
when looking for lto plugin.

10 years agoFix various warnings seen when using gcc-5.0
Alan Modra [Mon, 22 Sep 2014 08:39:49 +0000 (18:09 +0930)]
Fix various warnings seen when using gcc-5.0

* config/tc-m68k.c (md_assemble): Add assert to work around
bogus trunk gcc warning.
* config/tc-pj.h (md_convert_frag): Warning fix.
* config/tc-xtensa.c (xg_assemble_vliw_tokens): Warning fix.