[Bug ld/64] ld-scripts/size-1 FAIL for cygwin

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=64

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot 
gnu.org> ---
The master branch has been updated by Yao Qi <address@hidden>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c06cbd92be66d82eb323a8c6ec451c1dccc02107

commit c06cbd92be66d82eb323a8c6ec451c1dccc02107
Author: Yao Qi <address@hidden>
Date:   Fri Jul 24 14:40:34 2015 +0100

    Initialise target descrption after skipping extra traps for --wrapper

    Nowadays, when --wrapper is used, GDBserver skips extra traps/stops
    in the wrapper program, and stops at the first instruction of the
    program to be debugged.  However, GDBserver created target description
    in the first stop of inferior, and the executable of the inferior
    is the wrapper program rather than the program to be debugged.  In
    this way, the target description can be wrong if the architectures
    of wrapper program and program to be debugged are different.  This
    is shown by some fails in gdb.server/wrapper.exp on buildbot.

    We are testing i686-linux GDB (Fedora-i686) on an x86_64-linux box
    (fedora-x86-64-4) in buildbot, such configuration causes fails in
    gdb.server/wrapper.exp like this:

    spawn
/home/gdb-buildbot-2/fedora-x86-64-4/fedora-i686/build/gdb/testsuite/../../gdb/gdbserver/gdbserver
--once --wrapper env TEST=1 -- :2346
/home/gdb-buildbot-2/fedora-x86-64-4/fedora-i686/build/gdb/testsuite/outputs/gdb.server/wrapper/wrapper
    Process
/home/gdb-buildbot-2/fedora-x86-64-4/fedora-i686/build/gdb/testsuite/outputs/gdb.server/wrapper/wrapper
created; pid = 8795
    Can't debug 64-bit process with 32-bit GDBserver
    Exiting
    target remote localhost:2346
    localhost:2346: Connection timed out.
    (gdb) FAIL: gdb.server/wrapper.exp: setting breakpoint at marker

    See https://sourceware.org/ml/gdb-testers/2015-q3/msg01541.html

    In this case, program to be debugged ("wrapper") is 32-bit but wrapper
    program ("/usr/bin/env") is 64-bit, so GDBserver gets the 64-bit
    target description instead of 32-bit.

    The root cause of this problem is that GDBserver creates target
    description too early, and the rationale of fix could be creating
    target description once the GDBserver skips extra traps and inferior
    stops at the first instruction of the program we want to debug.  IOW,
    when GDBserver skips extra traps, the inferior's tdesc is NULL, and
    mywait and its callees shouldn't use inferior's tdesc, so in this
    patch, we skip code that requires register access, see changes in
    linux_resume_one_lwp_throw and need_step_over_p.

    In linux_low_filter_event, if target description isn't initialised and
    GDBserver attached the process, we create target description immediately,
    because GDBserver don't have to skip extra traps for attach, IOW, it
    makes no sense to use --attach and --wrapper together.  Otherwise, the
    process is launched by GDBserver, we keep the status pending, and return.

    After GDBserver skipped extra traps in start_inferior, we call a
    target_ops hook arch_setup to initialise target description there.

    gdb/gdbserver:

    2015-07-24  Yao Qi  <address@hidden>

        * linux-low.c (linux_arch_setup): New function.
        (linux_low_filter_event): If proc->tdesc is NULL and
        proc->attached is true, call the_low_target.arch_setup.
        Otherwise, keep status pending, and return.
        (linux_resume_one_lwp_throw): Don't call get_pc if
        thread->while_stepping isn't NULL.  Don't call
        get_thread_regcache if proc->tdesc is NULL.
        (need_step_over_p): Return 0 if proc->tdesc is NULL.
        (linux_target_ops): Install arch_setup.
        * server.c (start_inferior): Call the_target->arch_setup.
        * target.h (struct target_ops) <arch_setup>: New field.
        (target_arch_setup): New marco.
        * lynx-low.c (lynx_target_ops): Update.
        * nto-low.c (nto_target_ops): Update.
        * spu-low.c (spu_target_ops): Update.
        * win32-low.c (win32_target_ops): Update.

-- 
You are receiving this mail because:
You are on the CC list for the bug.