In skip_artificial_frames we repeatedly call get_prev_frame_always until we get
a non-inline and non-tailcall frame assuming that there must be such a frame
eventually.
For record targets, however, we may have a frame chain that consists only of
artificial frames. This leads to a crash in get_frame_type when dereferencing a
NULL frame pointer.
Change skip_artificial_frames and skip_tailcall_frames to return NULL in such a
case and modify each caller to cope with a NULL return.
In frame_unwind_caller_pc and frame_unwind_caller_arch, we simply assert that
the returned value is not NULL. Their caller was supposed to check
frame_unwind_caller_id before calling those functions.
In other cases, we thrown an error.
In infcmd further move the skip_tailcall_frames call to the forward-stepping
case since we don't need a frame for reverse execution and we don't want to fail
because of that. Reverse-finish does make sense for a tailcall frame.
gdb/
* frame.h (skip_tailcall_frames): New.
* infcmd.c (finish_command): Call skip_tailcall_frames.
* frame.c (skip_artificial_frames): Return NULL if only artificial frames
are found. Update comment.
(frame_pop): Call skip_tailcall_frames.
(frame_unwind_caller_id): Handle NULL return.
(frame_unwind_caller_pc, frame_unwind_caller_arch): Assert that
skip_artificial_frames does not return NULL.
(frame_pop): Add an error if only tailcall frames are found.
* infcmd.c (finish_command): Move skip_tailcall_frames call into forward-
execution case. Add an error if only tailcall frames are found.
* stack.c (frame_info): Check frame_unwind_caller_id.
Pedro Alves [Tue, 15 Mar 2016 16:33:04 +0000 (16:33 +0000)]
Fix PR gdb/19676: Internal error in linux-thread.db.c if /proc not mounted
If /proc is not mounted, GDB fails an assertion in find_new_threads_once:
Continuing.
.../src/gdb/linux-thread-db.c:1249: internal-error: find_new_threads_once: Assertion `!target_has_execution' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
That was supposed to catch misuses of td_ta_thr_iter, which is unsafe
for live debugging. However, if /proc is not mounted, we still
fallback to using it.
I didn't bother with a warning, because GDB already prints several
others related to failing to open /proc files.
gdb/ChangeLog:
2016-03-15 Pedro Alves <palves@redhat.com>
PR gdb/19676
* linux-thread-db.c (try_thread_db_load_1): Leave
info->td_ta_thr_iter_p NULL iff debugging a live process and we
have /proc access.
(find_new_threads_once): Assert that we have a non-NULL
info->td_ta_thr_iter_p instead of checking whether the target has
execution.
Jan Kratochvil [Mon, 22 Feb 2016 16:15:14 +0000 (17:15 +0100)]
gdb-gdb.py: SyntaxError: Missing parentheses in call to 'print'
After building GDB
--with-python=/usr/bin/python3
and for example stripping ./gdb and running:
./gdb -data-directory data-directory/ -iex "add-auto-load-safe-path $PWD/gdb-gdb.gdb" -iex "add-auto-load-safe-path $PWD/gdb-gdb.
py" ./gdb
I get:
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
File "/home/jkratoch/redhat/gdb-test-python3/gdb/gdb-gdb.py", line 91
print "Warning: Cannot find enum type_flag_value type."
^
SyntaxError: Missing parentheses in call to 'print'
(top-gdb) q
gdb/ChangeLog
2016-02-22 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb-gdb.py (class TypeFlagsPrinter): Use parentheses for print.
The cause of the problem was the following sequence of events:
* GDB knows only about the main thread
* the first fork event is reported to GDB, saved as pending_event
* qXfer:threads:read gets the threads from the remote.
remove_new_fork_children id's the fork child from the pending event
and removes it from the list reported to GDB. All the rest of the
threads, including the fork parent, are added to the GDB thread list.
* GDB stops all the threads. All the stop events are pushed onto the
stop reply queue behind the pending fork event. The fork waitstatus
is saved in the fork parent thread's pending status field
thread_info.suspend.
* remote_wait_ns calls queued_stop_reply and process_stop_reply to
remove the fork event from the front of the stop reply queue and save
event information in the thread_info structure for the fork parent
thread. Unfortunately, none of the information saved in this way is
the fork-specific information.
* A subsequent qXfer:threads:read packet gets the thread list including
the fork parent and fork child. remove_new_fork_children checks the
thread list to see if there is a fork parent, doesn't find one, checks
the stop reply queue for a pending fork event, doesn't find one, and
allows the fork child thread to be reported to GDB before the fork
event has been handled. remote_update_thread_list calls
remote_notice_new_thread and overwrites the current (main) thread in
inferior_appeared.
So the fork event has been reported out of target_wait but it was left
pending on the infrun side (infrun.c:save_waitstatus). IOW, the fork
event hasn't been processed by handle_inferior_event yet, so it hasn't
made it to tp->pending_follow yet.
The fix is to check thread_info.suspend along with the
thread_info.pending_follow in remote.c:remove_new_fork_children, to
prevent premature reporting of the fork child thread creation.
gdb/ChangeLog:
PR remote/19496
* remote.c (remove_new_fork_children): Check for pending
fork status in thread_info.suspend.
gdb/testsuite/ChangeLog:
PR remote/19496
* gdb.threads/forking-threads-plus-breakpoint.exp (do_test):
Remove kfail for PR remote/19496.
Yao Qi [Tue, 16 Feb 2016 13:56:41 +0000 (13:56 +0000)]
Fix cleanup in arm_linux_software_single_step
I see the following error in testing aarch64 GDB debugging arm
program.
(gdb) PASS: gdb.reverse/readv-reverse.exp: set breakpoint at marker2
continue
Continuing.
=================================================================
==32273==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x000000ce4c00 in thread T0
#0 0x2ba5615645c7 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x545c7)^M
#1 0x4be8b5 in VEC_CORE_ADDR_cleanup /home/yao/SourceCode/gnu/gdb/git/gdb/common/gdb_vecs.h:34^M
#2 0x5e6d95 in do_my_cleanups /home/yao/SourceCode/gnu/gdb/git/gdb/common/cleanups.c:154^M
#3 0x64c99a in fetch_inferior_event /home/yao/SourceCode/gnu/gdb/git/gdb/infrun.c:3975^M
#4 0x678437 in inferior_event_handler /home/yao/SourceCode/gnu/gdb/git/gdb/inf-loop.c:44^M
#5 0x5078f6 in remote_async_serial_handler /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:13223^M
#6 0x4cecfd in run_async_handler_and_reschedule /home/yao/SourceCode/gnu/gdb/git/gdb/ser-base.c:137^M
#7 0x676864 in gdb_wait_for_event /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:834^M
#8 0x676a27 in gdb_do_one_event /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:323^M
#9 0x676aed in start_event_loop /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:347^M
#10 0x6706d2 in captured_command_loop /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:318^M
#11 0x66db8c in catch_errors /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:240^M
#12 0x6716dd in captured_main /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:1157^M
#13 0x66db8c in catch_errors /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:240^M
#14 0x671b7a in gdb_main /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:1165^M
#15 0x467684 in main /home/yao/SourceCode/gnu/gdb/git/gdb/gdb.c:32^M
#16 0x2ba563ed7ec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)^M
#17 0x4676b2 (/scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/gdb+0x4676b2)
looks we should discard cleanup if function
arm_linux_software_single_step returns early, or create cleanup when
it is needed.
Jan Kratochvil [Mon, 15 Feb 2016 18:01:03 +0000 (19:01 +0100)]
Add missing gdb.arch/i386-prologue.c prototypes
The testfile has not ran because:
gdb.arch/i386-prologue.c:34:3: warning: implicit declaration of function 'standard' [-Wimplicit-function-declaration]
standard ();
^
gdb.arch/i386-prologue.c:35:3: warning: implicit declaration of function 'stack_align_ecx' [-Wimplicit-function-declaration]
stack_align_ecx ();
^
gdb.arch/i386-prologue.c:36:3: warning: implicit declaration of function 'stack_align_edx' [-Wimplicit-function-declaration]
stack_align_edx ();
^
gdb.arch/i386-prologue.c:37:3: warning: implicit declaration of function 'stack_align_eax' [-Wimplicit-function-declaration]
stack_align_eax ();
^
gdb/testsuite/ChangeLog
2016-02-15 Jan Kratochvil <jan.kratochvil@redhat.com>
Jan Kratochvil [Mon, 15 Feb 2016 17:54:03 +0000 (18:54 +0100)]
Fix more testcases with standard_output_file.
Since
commit 2151ccc56c74b55a8f0debf0724a495368f92591
Author: Simon Marchi <simon.marchi@ericsson.com>
Date: Mon Feb 8 14:02:36 2016 -0500
Always organize test artifacts in a directory hierarchy
these testfiles could not build.
gdb/testsuite/ChangeLog
2016-02-15 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/i386-gnu-cfi.exp: Use standard_output_file.
* gdb.arch/i386-prologue.exp: Likewise.
* gdb.arch/i386-size.exp: Likewise.
These issues get fixed (or removed if no longer applicable) by attached patch.
It is based on Googled:
http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html#5
When a pointer is declared its status is undefined, and cannot be
safely queried with the associated intrinsic.
-> nullify(VARNAME)
+
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/268786
ALLOCATE is not supposed to initialize the array.
-> Remove checks like an initial print is: \\( *0, *0, *0...\\)
These regressions remain:
-PASS: gdb.fortran/library-module.exp: print var_i in lib
+FAIL: gdb.fortran/library-module.exp: print var_i in lib
-PASS: gdb.fortran/library-module.exp: print var_i in main
+FAIL: gdb.fortran/library-module.exp: print var_i in main
I believe it is more a GDB bug (in a code contributed by me), filed:
gdb.fortran/library-module.exp false regression on GCC upgrade
https://sourceware.org/bugzilla/show_bug.cgi?id=19635
gdb/testsuite/ChangeLog
2016-02-14 Jan Kratochvil <jan.kratochvil@redhat.com>
> +static int max_value_size = 65536; /* 64k bytes */
FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was filled (passed fixed array)
FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was mofified in debugger (passed fixed array)
FAIL: gdb.fortran/vla-value-sub-finish.exp: print array2 in foo after it was filled
FAIL: gdb.fortran/vla-value-sub-finish.exp: print array2 in foo after it was mofified in debugger
print array2
value requires 296352 bytes, which is more than max-value-size
(gdb) FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was filled (passed fixed array)
gdb/testsuite/ChangeLog
2016-02-14 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.fortran/vla-value-sub-finish.exp (set max-value-size 1024*1024):
New test.
* gdb.fortran/vla-value-sub.exp: Likewise.
Yao Qi [Wed, 10 Feb 2016 16:40:52 +0000 (16:40 +0000)]
Clear *VAL in regcache_raw_read_unsigned
We have function regcache_raw_read_unsigned defined in both GDB and
GDBserver, so that it is used in common like this,
ULONGEST value;
status = regcache_raw_read_unsigned (regcache, regnum, &value);
'value' is correctly set in GDB side, but may not be correctly set
in GDBserver, because &value is passed in regcache_raw_read_unsigned
but collect_register may only set part of the whole variable. In my
test, I see the top half of 'value' is garbage. This patch fixes this
problem by clearing *VAL before calling collect_register.
Keith Seitz [Mon, 8 Feb 2016 20:57:22 +0000 (12:57 -0800)]
breakpoints/19546: Fix crash after updating breakpoints
One of the last checks update_breakpoints_after_exec does while looping
over the list of breakpoints is check that the breakpoint has a valid
location spec. It uses event_location_empty_p to check if the location spec
is "empty", and if it is, the breakpoint is deleted.
momentary_breakpoint types rely on setting the breakpoint structure's
location spec to NULL, thereby causing an update to delete the breakpoint.
However, event_location_empty_p assumed that locations were never NULL.
As a result, GDB would crash dereferencing a NULL pointer whenever
update_breakpoints_after_exec would encounter a momentary_breakpoint.
This patch creates a new wrapper/helper function which tests that the given
breakpoint's location spec is non-NULL and if it is not "empty"
or "unspecified."
gdb/ChangeLog
PR breakpoints/19546
* breakpoint.c (breakpoint_event_location_empty_p): New function.
(update_breakpoints_after_exec, bkpt_re_set): Use this new function
instead of event_location_empty_p.
gdb/testsuite/ChangeLog
PR breakpoints/19546
* gdb.base/infcall-exec.c: New file.
* gdb.base/infcall-exec2.c: New file.
* gdb.base/infcall-exec.exp: New file.
Keith Seitz [Tue, 9 Feb 2016 18:02:54 +0000 (10:02 -0800)]
Enable/update legacy linespecs in MI.
MI is currently using string_to_event_location to enable the use of legacy
linespecs, but using this function (until this patchset) had the (as yet
unnoticed) side effect of allowing both MI and CLI representation for
explicit locations.
This patch simply changes MI to use the same legacy linespec functions
that the python and guile interpreters use. This eliminates the CLI syntax
for explicit locations (in MI).
gdb/ChangeLog
* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Use
string_to_event_location_basic instead of string_to_event_location.
Keith Seitz [Tue, 9 Feb 2016 18:02:53 +0000 (10:02 -0800)]
Use string_to_event_location_basic in guile.
This patch, analogous to the previous python patch, implements proper
legacy linespec support in guile code using the newly introduced
string_to_event_location_basic.
gdb/ChangeLog
* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Skip
leading whitespace and use string_to_event_location_basic instead
of new_linespec_location.
gdb/testsuite/ChangeLog
* gdb.guile/scm-breakpoint.exp (test_bkpt_address): New procedure.
(toplevel): Call test_bkpt_address.
Now that "legacy" linespecs benefit from consolidated support in
string_to_event_location_basic, python's Breakpoint command should use this
function to turn strings into event locations.
As a result, this patch fixes python/19506. Before:
(gdb) python gdb.Breakpoint("*main")
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Function "*main" not defined.
Error while executing Python code.
After:
(gdb) python gdb.Breakpoint("*main")
Breakpoint 1 at 0x4005fb: file ../../../src/gdb/testsuite/gdb.python/py-breakpoint.c, line 32.
gdb/ChangeLog
PR python/19506
* python/py-breakpoint.c (bppy_init): Use
string_to_event_location_basic instead of new_linespec_location.
gdb/testsuite/ChangeLog
PR python/19506
* gdb.python/py-breakpoint.exp (test_bkpt_address): New procedure.
(toplevel): Call test_bkpt_address.
Keith Seitz [Tue, 9 Feb 2016 18:02:53 +0000 (10:02 -0800)]
Refactor string_to_event_location for legacy linespec support.
This patch refactors string_to_event_location, breaking it into two
separate functions:
1) string_to_event_location_basic
A "basic" string parser that implements support for "legacy" linespecs
(linespec, address, and probe locations). This function is intended to
be used by any UI wishing/needing to support this legacy behavior.
2) string_to_event_location
This is now intended as a CLI-only function which adds explicit location
parsing in a CLI-appropriate manner (in the form of traditional option/value
pairs).
Together these patches serve to simplify string-to-event location parsing
for all existing non-CLI interfaces (MI, guile, and python).
gdb/ChangeLog
* location.c (string_to_explicit_location): Note that "-p" is
reserved for probe locations and return NULL for any input
that starts with that.
(string_to_event_location): Move "legacy" linespec code to ...
(string_to_event_location_basic): ... here.
* location.h (string_to_event_location): Update comment.
(string_to_event_location_basic): New function.
Simon Marchi [Tue, 9 Feb 2016 14:01:58 +0000 (09:01 -0500)]
Modernize configure.ac's
Using AC_OUTPUT with arguments has been deprecated for some time in
autoconf, even in version 2.64, which we are using. This change should
not affect functionality.
I also removed the "exit 0"'s, they shouldn't be necessary.
gdb/ChangeLog:
* configure.ac: Use AC_CONFIG_FILES instead of passing arguments
to AC_OUTPUT. Remove "exit 0" at the end.
* configure: Regenerate.
gdb/testsuite/ChangeLog:
* configure.ac: Use AC_CONFIG_FILES instead of passing arguments
to AC_OUTPUT.
* configure: Regenerate.
gdb/gdbserver/ChangeLog:
* configure.ac: Use AC_CONFIG_FILES instead of passing arguments
to AC_OUTPUT.
* configure: Regenerate.
Pedro Alves [Tue, 9 Feb 2016 12:12:17 +0000 (12:12 +0000)]
Fix PR19548: Breakpoint re-set inserts breakpoints when it shouldn't
PR19548 shows that we still have problems related to 13fd3ff34329:
[PR17431: following execs with "breakpoint always-inserted on"]
https://sourceware.org/ml/gdb-patches/2014-09/msg00733.html
The problem this time is that we currently update the global location
list and try to insert breakpoint locations after re-setting _each_
breakpoint in turn.
Say:
- We have _more_ than one breakpoint set. Let's assume 2.
- There's a breakpoint with a pre-exec address that ends up being an
unmapped address after the exec.
- That breakpoint is NOT the first in the breakpoint list.
Then when handling an exec, and we re-set the first breakpoint in the
breakpoint list, we mistakently try to install the old pre-exec /
un-re-set locations of the other breakpoint, which fails:
(gdb) continue
Continuing.
process 28295 is executing new program: (...)/execl-update-breakpoints2
Error in re-setting breakpoint 1: Warning:
Cannot insert breakpoint 2.
Cannot access memory at address 0x1000764
Breakpoint 1, main (argc=1, argv=0x7fffffffd368) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/execl-update-breakpoints.c:34
34 len = strlen (argv[0]);
(gdb)
Fix this by deferring the global location list update till after all
breakpoints are re-set.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/ChangeLog:
2016-02-09 Pedro Alves <palves@redhat.com>
PR breakpoints/19548
* breakpoint.c (create_overlay_event_breakpoint): Don't update
global location list here.
(create_longjmp_master_breakpoint)
(create_std_terminate_master_breakpoint)
(create_exception_master_breakpoint, create_jit_event_breakpoint)
(update_breakpoint_locations):
(breakpoint_re_set): Update global location list after all
breakpoints are re-set.
gdb/testsuite/ChangeLog:
2016-02-09 Pedro Alves <palves@redhat.com>
PR breakpoints/19548
* gdb.base/execl-update-breakpoints.c (some_function): New
function.
(main): Call it.
* gdb.base/execl-update-breakpoints.exp: Add a second breakpoint.
Tighten expected GDB output.
Nick Clifton [Tue, 9 Feb 2016 09:56:21 +0000 (09:56 +0000)]
Add a more helpful warning message to explain why some AArch64 relocations can overflow.
bfd * elfnn-aarch64.c (elfNN_aarch64_relocate_section): Add a more
helpful warning message to explain why certain AArch64 relocs
might overflow.
ld * testsuite/ld-aarch64/reloc-overflow-bad.d: New test.
* testsuite/ld-aarch64/reloc-overflow-1.s: New source file.
* testsuite/ld-aarch64/reloc-overflow-2.s: New source file.
* testsuite/ld-aarch64/aarch64-elf.exp: Run the new test.
Nick Clifton [Tue, 9 Feb 2016 09:56:21 +0000 (09:56 +0000)]
Add a more helpful warning message to explain why some AArch64 relocations can overflow.
bfd * elfnn-aarch64.c (elfNN_aarch64_relocate_section): Add a more
helpful warning message to explain why certain AArch64 relocs
might overflow.
ld * testsuite/ld-aarch64/reloc-overflow-bad.d: New test.
* testsuite/ld-aarch64/reloc-overflow-1.s: New source file.
* testsuite/ld-aarch64/reloc-overflow-2.s: New source file.
* testsuite/ld-aarch64/aarch64-elf.exp: Run the new test.
Simon Marchi [Mon, 8 Feb 2016 19:02:36 +0000 (14:02 -0500)]
Always organize test artifacts in a directory hierarchy
When running tests in parallel, each test puts its generated files in a
different directory, under "outputs". I think it would be nice if it
was always the case, as it would isolate the test cases a bit more. An
artifact created by a test wouldn't get overwritten by another test.
Also, it makes it easier to clean up. A lot of executables are left all
over the place because their names do not appear in gdb.*/Makefile. If
everything is in "outputs", then we just have to delete that directory
(which we already do).
At the same time it makes the gdb.foo directories and their Makefiles
useless in the build directory, since they are pretty much only used for
cleaning.
Simon Marchi [Mon, 8 Feb 2016 19:00:49 +0000 (14:00 -0500)]
Fix in-tree, parallel running of Ada tests
While testing the following patch,
[PATCH] Always organize test artifacts in a directory hierarchy
https://sourceware.org/ml/gdb-patches/2016-01/msg00133.html
I noticed that it broke Ada testing. This lead me to think that
parallel testing when building in-tree didn't work previously in Ada.
It is confirmed by this test:
This patch fixes in-tree parallel testing for Ada, and consequently
serial and parallel testing when the aforementioned patch is applied.
The problem originates from the fact that Ada support code cd's to the
builddir before compiling. In itself it's not a problem, it allows to
place intermediate auto-generated files in that directory. The Ada
compilation refers to the source file, which is in another directory,
only by its base name (e.g. foo.adb). In serial mode, that worked
because builddir was the same as the source directory (e.g.
gdb.ada/fun_addr/). In an out-of-tree build, it works because the
source directory is added as an include directory (note: this is not the
same $srcdir as autoconf's):
set srcdir [file dirname $source]
additional_flags=-I$srcdir
However, when building in-tree, srcdir is relative: ./gdb.ada/fun_addr.
When using parallel or always-in-outputs-directory mode, we are cd'ed in
the outputs directory. So -I$srcdir is relative to the current
directory, which is wrong.
To fix it, I made the TCL variable srcdir (set in site.exp, from which
everything else is derived) always absolute. It is done by assigning
autoconf's abs_srcdir instead of autoconf's srcdir. This way -I$srcdir
will always be good, regardless of where we cd'ed to. A small apparent
change is that when running tests, DejaGnu will say:
Cary Coutant [Sun, 7 Feb 2016 06:42:16 +0000 (22:42 -0800)]
Fix incorrect x32 overflow checking for refs to weak undef symbols.
On x32, a pc-relative reference to an undef weak symbol (value 0)
with a negative addend (typically -4) generates a spurious overflow
error because Symbol_value::value() returns a 32-bit negative number
as an unsigned number, which gets zero-extended before subtracting
the PC value. This patch fixes the problem by special-casing the
negative addend, and adding it to the value after widening it to
64 bits. Symbol_value::value() does not need the addend if it's
negative, since it is only important when processing section
symbols for merge sections, where a positive addend provides the
input section offset of the merged constant.
gold/
* x86_64.cc (X86_64_relocate_functions::pcrela32_check): Fix x32
overflow checking when symbol value + addend < 0.
Simon Marchi [Sun, 7 Feb 2016 14:45:02 +0000 (09:45 -0500)]
varobj: Cleanup dead code
This patch removes some dead code.
I noticed that varobj_delete was always called with dellist == NULL, so
I started removing that parameter. That allows removing a good chunk of
the code in varobj_delete, making it almost trivial. We can also remove
the resultp parameters in that whole trail. In turn, this shows that
struct cpstack, cppush and cppop were only used fo that mechanism, so
they can be removed as well.
I also moved the function comment to the header file to comply with
today's guideline, even though the rest of the file does not respect it
(yet).
Cary Coutant [Sun, 7 Feb 2016 02:18:51 +0000 (18:18 -0800)]
Fix compile errors about shift counts too large.
In order to get around the optimizer and newer compiler warnings
about shift counts, the overflow checking code had resorted to
some messy shifting, and with the never-before-seen instantiations
of the template functions, we were still running afoul of the
compiler checks.
This patch replaces those messy shift sequences with a simple
class template that provides the min and max limits for any
bit size up to 64, with a specialization for 64 that prevents
the compiler from complaining.
gold/
PR gold/19577
* reloc.h (Limits): New class.
(Bits::has_overflow32): Use min/max values from Limits.
(Bits::has_unsigned_overflow32): Likewise.
(Bits::has_signed_unsigned_overflow32): Likewise.
(Bits::has_overflow): Likewise.
(Bits::has_unsigned_overflow): Likewise.
(Bits::has_signed_unsigned_overflow64): Likewise.
Cary Coutant [Sat, 6 Feb 2016 22:47:05 +0000 (14:47 -0800)]
Fix overflow checking for 32-bit pc-relative relocations on x32.
The problem here is that x32 is really using 64-bit addressing,
while pretending to be 32-bit. Even though the object file format
is 32-bit, we need to do the overflow checking with 64-bit
arithmetic (because that's what the hardware will be using).
This patch overrides the pcrela32_check functions in reloc.h
with target-specific versions that do 64-bit checking.
I've also updated the test case to use -Tdata instead of adding
a huge .space directive, to reduce the size of the .o files.
gold/
PR gold/19567
* reloc.h (Relocate_functions::Overflow_check): Add comments.
* x86_64.cc (X86_64_relocate_functions): New class.
(Target_x86_64::Relocate::relocate): Use the new class.
* testsuite/Makefile.am (x86_64_overflow_pc32): Add -Tdata option.
(x32_overflow_pc32): New test case.
* testsuite/Makefile.in: Regenerate.
* testsuite/x32_overflow_pc32.sh: New script.
* testsuite/x86_64_overflow_pc32.s: Remove .space directive.
Sriraman Tallam [Fri, 5 Feb 2016 23:07:45 +0000 (15:07 -0800)]
2016-02-05 Sriraman Tallam <tmsriram@google.com>
* icf.cc (get_rel_addend): New function.
(get_section_contents): Move merge section addend computation to a
new function. Ignore negative values for SHT_REL and SHT_RELA addends.
Fix bug to not read past the length of the section.
Fix bug related to addend computation for MERGE sections.
Cary Coutant [Fri, 5 Feb 2016 17:19:47 +0000 (09:19 -0800)]
Add some relocation overflow checks for x86_64.
2016-02-05 Cary Coutant <ccoutant@gmail.com>
Andrew Senkevich <andrew.senkevich@intel.com>
gold/
PR gold/18695
* x86_64.cc (Target_x86_64::Relocate::relocate): Add overflow
checking for R_X86_64_32, R_X86_64_32S, R_X86_64_PC32, and
R_X86_64_PLT32.
* testsuite/Makefile.am (x86_64_overflow_pc32): New test.
* testsuite/x86_64_overflow_pc32.sh: New test script.
* testsuite/x86_64_overflow_pc32.s: New source file.
projects / thirdparty / binutils-gdb.git / log
