Before this, a copy constructor declared as in the following snippet was
not being treated as a copy constructor.
class A
{
public:
A (A &); // OK.
A (const A &); // Not being treated as a copy constructor because of the
// 'const' qualifier.
};
gdb/ChangeLog:
PR c++/13403
PR c++/15154
* gnu-v3-abi.c (gnuv3_pass_by_reference): Lookup copy constructors
with qualified args.
Test gdb.python/py-parameter.exp expects output "$srcdir/$subdir:\$cdir:\$cwd",
but proc gdb_reinitialize_dir doesn't set $srcdir/$subdir in search
directories on remote host because it doesn't exist on remote host.
proc gdb_reinitialize_dir { subdir } {
global gdb_prompt
if [is_remote host] {
return ""
}
It causes the fail below:
(gdb) python print (gdb.parameter ('directories'))^M
/tmp/gdb:$cdir:$cwd^M
(gdb) FAIL: gdb.python/py-parameter.exp: python print (gdb.parameter ('directories'))
This patch is to fix this fail by not matching $srcdir/$subdir on remote host.
gdb/testsuite:
2014-10-15 Yao Qi <yao@codesourcery.com>
* gdb.python/py-parameter.exp: Don't match $srcdir/$subdir on
remote host.
I see the following fails in the remote host testing we do for mingw32
hosted GDB,
python print (symtab[1][0].symtab)^M
python.c^M
(gdb) FAIL: gdb.python/python.exp: Test decode_line current locationn filename
python print (symtab[1][0].symtab)^M
python.c^M
(gdb) FAIL: gdb.python/python.exp: Test decode_line python.c:26 filename
The test cases doesn't consider remote host and assumes that directory
on build also exists on host. In this patch, we only match file base
name if host is remote, otherwise, match file with dir name.
gdb/testsuite:
2014-10-15 Yao Qi <yao@codesourcery.com>
* gdb.python/py-symbol.exp: Match file base name if host is
remote, otherwise match file name with dir name.
* gdb.python/py-symtab.exp: Likewise.
* gdb.python/python.exp: Likewise.
This patch is to clean up various gdb.python/*.exp tests, such as
removing trailing ".*" from the pattern and fix one typo I find during
reading the code.
gdb/testsuite:
2014-10-15 Yao Qi <yao@codesourcery.com>
* gdb.python/python.exp: Remove trailing ".*". Fix typo
locationn.
* gdb.python/py-symbol.exp: Remove trailing ".*" in the
pattern.
* gdb.python/py-symtab.exp: Likewise.
* ldlex.l (INPUTLIST): New start condition.
(comment pattern, ",", "(", ")", "AS_NEEDED")
({FILENAMECHAR1}{FILENAMECHAR}*, "-l"{FILENAMECHAR}+)
(quoted string pattern, whitespace pattern): Add INPUTLIST to
valid start conditions.
(<INPUTLIST>"="{FILENAMECHAR1}{FILENAMECHAR}*): New NAME rule.
(ldlex_inputlist): New start-condition-setter function.
* ldgram.y (input_list1): Rename from input_list. All recursive
use changed.
(input_list): New wrapper rule for input_list1, setting
INPUTLIST lexer state for the duration of parsing input_list1.
All this to say INPUT(=/path/to/file) and not be forced to use
INPUT("=/path/to/file") whenever there's a need to force a sysroot-
prefix. Still, IMHO it seems better to make use of a previously
invalid syntax and not only change the meaning of quoted =-prefixed
paths (though arguably that's not very useful before this patchset).
This got a little bit hairier than I'd expected: I had to add a new
lexer state (aka. start condition) to avoid a first "=" being lexed as
the token "=", despite that not making sense in constructs expecting
file-names in the first place. (The grammar doesn't allow for
expressions in any part of those lists.) I guess I *could* have made
it work using that token anyway, but I didn't like the idea that you
would be able to separate the "=" from the rest of the file-name with
whitespace.
* ldlang.c (lang_add_input_file): If the first character in the
filename is '=', prepend the sysroot and force the context of that
input file to non-sysroot.
The "input_flags.sysrooted = 0" thing described in the comment is
covered by the testsuite part ("root-anchored =-prefixed script
inside"), but only observable for --with-sysroot configurations.
* ld-scripts/sysroot-prefix.exp, ld-scripts/sysroot-prefix-x.s,
ld-scripts/sysroot-prefix-y.s: New files.
N.B: full coverage is only possible with complementary use of
--with-sysroot when configuring.
* ld.texinfo (input files in linker scripts): When mentioning
behavior of first character "/" on scripts within sysroot, also
mention that effect can be forced by prefixing with "=" and
refer to SEARCH_DIR.
If src contains n or more bytes, strncat() writes n+1 bytes to dest
(n from src plus the terminating null byte). Therefore, the size of
dest must be at least strlen(dest)+n+1.
* config/tc-tic4x.c (md_assemble): Correct strncat size.
When trying to evaluate an expression which adds a pointer and
an integral, the evaluation succeeds if the pointer is on
the left handside of the operator, but not when it is on the right
handside:
(gdb) p something'address + 0
$1 = (system.address) 0x613418 <pck.something>
(gdb) p 0 + something'address
Argument to arithmetic operation not a number or boolean.
Same issue when doing subtractions:
(gdb) p something'address - 0
$2 = (system.address) 0x613418 <pck.something>
(gdb) p 0 - something'address
Argument to arithmetic operation not a number or boolean.
This patch enhances the Ada expression evaluator to handle
these two situations.
gdb/ChangeLog:
* ada-lang.c (ada_evaluate_subexp) <BINOP_ADD>: Add handling
of the case where the second operand is a pointer.
<BINOP_SUB>: Likewise.
gdb/testsuite/ChangeLog:
* gdb.ada/addr_arith: New testcase.
Tested on x86_64-linux.
This patch is a response to what I commented on:
<https://sourceware.org/ml/gdb-patches/2014-10/msg00046.html>
When reviewing Jose's USDT probe support patches. Basically, in his
patch he had to create dummy functions for the set_semaphore and the
clear_semaphore methods of probe_ops (gdb/probe.h), because those
functions were called inconditionally from inside gdb/breakpoint.c and
gdb/tracepoint.c. However, the semaphore concept may not apply to all
types of probes, and this is the case here: USDT probes do not have
semaphores (although SDT probes do).
Anyway, this is a simple (almost obvious) patch to guard the call to
{set,clear}_semaphore. It does not introduce any regression on a
Fedora 20 x86_64.
I will apply it in a few days in case there is no comment.
gdb/ChangeLog:
2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com>
* breakpoint.c (bkpt_probe_insert_location): Call set_semaphore
only if it is not NULL.
(bkpt_probe_remove_location): Likewise, for clear_semaphore.
* probe.h (struct probe_ops) <set_semaphore>: Update comment.
(struct probe_ops) <clear_semaphore>: Likewise.
* tracepoint.c (start_tracing): Call set_semaphore only if it is
not NULL.
(stop_tracing): Likewise, for clear_semaphore.
Joel contacted me offlist with a question about a warning that one of
his customers was seeing. The message came from the new
linker-debugger interface, which uses SDT probes internally. The
warning said:
(gdb) run
[...]
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
Argument to arithmetic operation not a number or boolean.
This should not have happened in the environment the customer was
using (RHEL-6.x), so I found it strange. Another thing caught my
attention: the last message, saying "Argument to arithmetic operation
not a number or boolean.".
Joel kindly investigated the issue further, and found the answer for
this. To quote him:
(gdb) set lang c
(gdb) p 48+$ebp
$4 = (void *) 0xffffd0f8
So far so good. But...
(gdb) set lang ada
(gdb) p 48+$ebp
Argument to arithmetic operation not a number or boolean.
Ooops! Interestingly, if you revert the order of the operands...
(gdb) p $ebp+48
$5 = (access void) 0xffffd0f8
So the problem is doing pointer arithmetics when the language is set
to Ada.
I remembered that, during the parsing and the evaluation of SDT probe
arguments, the code sets the language as current_language, because, at
that time, I thought it was not necessary to worry about the language
given that the code implements its own parser. I was wrong. So here
is a patch to fix that, by setting the language as C, which should
guarantee that the maths are done in the right way (TM).
It was somewhat hard to find a reproducer for this issue. In the end,
what I had to do was to create a testcase that used the %ebp register
on some displacement (e.g., "-4(%ebp)"), which finally triggered the
bug. I am not sure why I could not trigger it when using other
registers, but I did not want to spend too much time investigating
this issue, which seemed like an Ada issue. Also, because of this
peculiar way to trigger the problem, the testcase only covers x86-like
targets (i.e., i*86 and x86_64 with -m32).
Joel kindly tested this for me, and it worked. I also ran a full
regression test here on my Fedora 20 x86_64, and everything is fine.
I will push this patch in a few days if there are no comments.
gdb/ChangeLog:
2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com>
* stap-probe.c (stap_parse_argument): Initialize expout explicitly
using language_c, instead of current_language.
gdb/testsuite/ChangeLog:
2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.arch/stap-eval-lang-ada.S: Likewise.
* gdb.arch/stap-eval-lang-ada.c: Likewise.
* gdb.arch/stap-eval-lang-ada.exp: New file.
Hi,
I see the following fails on arm-none-eabi target,
-var-list-children --simple-values struct_declarations ^M
^done,numchild="11",children=[...,child={name="struct_declarations.func_ptr_struct",exp="func_ptr_struct",numchild="0",value="0x0 <_ftext>",type="struct _struct_decl (*)(int, char *, long)",thread-id="1"},child={name="struct_declarations.func_ptr_ptr",exp="func_ptr_ptr",numchild="0",value="0x0 <_ftext>",type="struct _struct_decl *(*)(int, char *, long)",thread-id="1"},...
(gdb) ^M
FAIL: gdb.mi/mi-var-child.exp: listing of children, simple types: names, type and values, complex types: names and types
-var-set-format weird.func_ptr_ptr natural^M
^done,format="natural",value="0x0 <_ftext>"^M
(gdb) ^M
FAIL: gdb.mi/mi-var-display.exp: set format variable weird.func_ptr_ptr in natural
In the test, "0x0" is expected, but "0x0 <_ftext>" is in the output.
Function pointers point to address zero, and tests assume there is no
symbol on address zero. However, on my arm-none-eabi target, there is
a code symbol _ftext on address zero, and test fails. Note that "set
print symbol off" doesn't take effect for function pointer.
int (*f) (void);
f = main;
(gdb) p f
$1 = (int (*)(void)) 0x8048400 <main>
(gdb) set print symbol off
(gdb) p f
$2 = (int (*)(void)) 0x8048400 <main>
In order to erase the difference, we can assign some function address
explicitly to function pointer, so the test behaves in a unique way.
In this patch, we assign nothing1 and nothing2 to function pointers
func_ptr_struct and func_ptr_ptr respectively, and update test as the
source file is changed.
gdb/testsuite:
2014-10-14 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-var-child.c (nothing1): New function.
(nothing2): New function.
(do_children_tests): Set function pointers by nothing1 and
nothing2.
* gdb.mi/mi-var-child.exp: Step over new added statements.
Update test to match the new output.
* gdb.mi/var-cmd.c (nothing1): New function.
(nothing2): New function.
(do_children_tests): Set function pointers by nothing1 and
nothing2.
* gdb.mi/mi-var-display.exp: Update test to match output.
Step to the line specified by $line_dct_nothing.
Increase the number of lines to step.
Hi,
I modify mi-var-child.exp and find that the pattern to match the output
of -var-update * is quite complicated. However, it can be simplified by
using mi_varobj_update. That is what this patch does.
gdb/testsuite:
2014-10-14 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-var-child.exp: Use mi_varobj_update to simplify
tests.
* gdb.mi/mi2-var-child.exp: Likewise.
%<number>s as an fscanf format does not include the trailing NULL.
PATH_MAX does include the trailing NULL.
PR 17453
* readelf.c (process_program_headers): Correct fscanf format used
for interpreter.
This test will pass if the CU is the first CU in the binary.
If libc debugging info is installed it may not be, in which case
the CU offset values are wrong.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-op-out-param.S: Make DW_FORM_ref4 values be the offset
from the start of the CU.
gdb/ChangeLog:
* py-objfile.c (objfpy_initialize): New function.
(objfpy_new, objfile_to_objfile_object): Call it.
* py-progspace.c (pspy_initialize): New function.
(pspy_new, pspace_to_pspace_object): Call it.
The idea here is to drop .eh_frame FDEs corresponding to dropped
comdat group sections or linkonce sections, but not perform changes in
encoding.
bfd/
PR 17467
* elf-eh-frame.c (ENSURE_NO_RELOCS): Don't stop at first NONE reloc.
(_bfd_elf_parse_eh_frame): When relocatable output, don't set
flags enabling conversion of CIEs and FDEs to use relative encoding.
(find_merged_cie): Similarly.
(_bfd_elf_write_section_eh_frame): Don't edit FDEs when
relocatable, except for CIE pointer.
* elflink.c (bfd_elf_reloc_symbol_deleted_p): Return true for
relocs against symbols in dropped comdat group sections.
(bfd_elf_discard_info): Do some eh_frame optimisation when
relocatable.
ld/
* ldlang.c (lang_add_section): Set up map_head.s and map_tail.s when
relocatable.
gdb/ChangeLog
2014-10-13 Miroslav Franc <mfranc@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Fix "save breakpoints" for "catch" command.
* break-catch-sig.c (signal_catchpoint_print_recreate): Add trailing
newline.
gdb/testsuite/ChangeLog
2014-10-13 Jan Kratochvil <jan.kratochvil@redhat.com>
Yao Qi <yao@codesourcery.com>
Fix "save breakpoints" for "catch" command.
* gdb.base/catch-signal.exp: Add gdb_breakpoint "main".
Remove -nonewline. Match also the added "main" line.
But IMO it is a functionality regression as:
* gdb_test_sequence permits arbitary number of lines of text between those
lines being matched. Former regex string did not allow it.
This may make a difference if GDB regresses by printing some unexpected
line after the breakpoint info line (like a "silent" line).
> * \[\r\n\]+ can be used to anchor the beginning of the pattern, in the sense
> of Perl regex ^ /m match. At least I have found such cases in existing
> *.exp files so I used that. Using ^ really does not work.
>
> But I am not aware how to do Perl regex $ /m match. Using $ really does
> not work. But this means that for example the trailing
> ( \\((host|target) evals\\))?
> on the line
> "\[\r\n\]+\[ \t\]+stop only if i == 1( \\((host|target) evals\\))?"
> originally made sense there but now it can be removed as it has no longer
> any functionality there - it will match now any trailing line garbage.
by Yao Qi:
In this test case, ( \\((host|target) evals\\))? isn't needed in the
pattern. What we test here is to save breakpoints into file and restore
them from file. The contents saved in file are:
break save-bp.c:31
condition $bpnum i == 1
the information about the place where the condition is evaluated isn't
saved, so we don't need to check. Breakpoint save and restore has
nothing to do with where the condition is evaluated (host or target). I
am fine to leave it here now.
gdb/testsuite/ChangeLog
2014-10-09 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/save-bp.exp (info break): Use gdb_test_sequence.
Nowadays, we are using command "tstatus" to send a packet to GDBserver
in order to check the connection. However, on the target doesn't
support tracepoint, the following error is emitted before sending any
packet to GDBserver.
tstatus^M
Trace can not be run on this target.^M
(gdb) FAIL: gdb.server/server-kill.exp: tstatus
qTStatus is disabled after receiving the empty reply during connecting
to the remote target. When the test executes command "tstatus" again,
remote_get_trace_status returns -1 at the very beginning, and no RSP
packet is sent out.
This patch is to enable qTStatus packet again.
gdb/testsuite:
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.server/server-kill.exp: Execute command
"set remote trace-status-packet on" before "tstatus".
Hi,
We see the following fail in the real remote testing...
(gdb) Executing on target: kill -9 29808 (timeout = 300)
spawn [open ...]^M
sh: 1: kill: No such process
The test tries to kill gdbserver in this way:
set server_pid [exp_pid -i [board_info target fileid]]
remote_exec target "kill -9 $server_pid"
in native testing, we'll get the pid of spawned gdbserver, however, in
remote testing, we'll get the pid of ssh session, since we start
gdbserver on the remote target through ssh. The pid on build doesn't
exist on target.
In this patch, we tweak server-kill.c to get the parent pid, which is
the pid of GDBserver. GDB gets it and kill GDBserver on target.
gdb/testsuite:
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.server/server-kill.c: Include sys/types.h and unistd.h.
(main): Call getppid.
* gdb.server/server-kill.exp: Set breakpoint on line "i = 0;"
and continue to it. Read variable "server_pid".
This patch is to remove some lines which looks unnecessary. These
lines were added when server-kill.exp was added. In the version 1,
https://sourceware.org/ml/gdb-patches/2013-03/msg00691.html the test
calls runto_main and delete breakpoint on main,
+if ![runto_main] {
+ return -1
+}
+
+# Otherwise the breakpoint at 'main' would not cause insert
breakpoints during
+# first step.
+delete_breakpoints
However, in the version 2
https://sourceware.org/ml/gdb-patches/2013-03/msg00854.html runto_main
is removed but delete_breakpoints is still there. AFAICS, the line of
delete_breakpoints can be removed too.
gdb/testsuite:
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.server/server-kill.exp: Remove "delete_breakpoints".
As the result of the patch below, GDB updates thread list when a stop is
presented to user. The tests don't have to fetch thread list explicitly.
[PATCH 3/3] Fix non-stop regressions caused by "breakpoints always-inserted off" changes
https://sourceware.org/ml/gdb-patches/2014-09/msg00734.html
This patch is to remove the test code updating thread list.
Run these three tests many times on arm-linux-gnueabi and x86-linux.
No regressions.
gdb/testsuite:
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.threads/thread-find.exp: Don't execute command
"info threads".
* gdb.threads/attach-into-signal.exp (corefunc): Likewise.
* gdb.threads/linux-dp.exp: Don't check the condition
$threads_created equals to zero.
This does most of the mechanical removal. IOW, the easy part.
This doesn't touch procfs.c as that'd be a harder excision,
potentially affecting Solaris.
mips-tdep.c is left alone. E.g., I didn't delete the GDB_OSABI_IRIX
enum value, nor references to it in mips-tdep.c. Some comments
mentioning IRIX ABIs may still be relevant and I wouldn't know what to
do with them. in That can always be done on a separate pass,
preferably by someone who can test on MIPS.
I didn't remove a reference to IRIX in testsuite/lib/future.exp, as I
believe that code is imported from DejaGNU.
Built and tested on x86_64 Fedora 20, with --enable-targets=all.
Tested that building for --target=mips-sgi-irix6 on x86_64 Fedora 20
fails with:
checking for default auto-load directory... $debugdir:$datadir/auto-load
checking for default auto-load safe-path... $debugdir:$datadir/auto-load
*** Configuration mips-sgi-irix6 is obsolete.
*** Support has been REMOVED.
make[1]: *** [configure-gdb] Error 1
make[1]: Leaving directory `/home/pedro/gdb/mygit/build-irix'
make: *** [all] Error 2
gdb/
2014-10-10 Pedro Alves <palves@redhat.com>
* Makefile.in (ALL_TARGET_OBS): Remove mips-irix-tdep.o and solib-irix.o.
(ALLDEPFILES): Remove mips-irix-tdep.c and solib-irix.c.
(HFILES_NO_SRCDIR): Remove solib-irix.h.
* NEWS: Mention that support for mips-sgi-irix5* mips-sgi-irix6*
and been removed.
* config/mips/irix5.mh, config/mips/irix6.mh: Delete files.
* configure.ac: Remove references to IRIX.
* configure.host: Add *-*-irix* to the obsolete hosts section.
Remove all other references to irix.
* irix5-nat.c, mips-irix-tdep.c, solib-irix.c, solib-irix.h:
Delete files.
gdb/testsuite/
2014-10-10 Pedro Alves <palves@redhat.com>
* gdb.base/bigcore.exp: Remove references to IRIX.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/interrupt.exp: Likewise.
* gdb.base/mips_pro.exp: Likewise.
* gdb.base/nodebug.exp: Likewise.
* gdb.base/setvar.exp: Likewise.
* lib/gdb.exp (gdb_compile_shlib): Remove mips-sgi-irix* case.
We currently validate the target description, but then forget to
reject it if found invalid.
Tested that incorrect descriptions are rejected and GDB warns about
them.
Tested the Microblaze Design with and without stack-protect registers.
The gdb command "info registers" displayed the register correctly. If
a stack protect design is not selected, only core registers are
displayed. When the stack-protect registers are selected in the
design, the core registers along with stack-protect registers are
displayed.
gdb/
2014-10-10 Ajit Agarwal <ajitkum@xilinx.com>
* microblaze-tdep.c (microblaze_gdbarch_init): If the description
isn't valid, release the tdesc arch data and return NULL.
We're now doing a vsyscall/vDSO address range lookup whenever we fetch
shared libraries, either through an explicit "info shared", or when
the target reports new libraries have been loaded, in order to filter
out the vDSO from glibc's DSO list. Before we started doing that, GDB
would only ever lookup the vsyscall's address range once in the
process's lifetime.
Looking up the vDSO address range requires an auxv lookup (which is
already cached, so no problem), but also reading the process's
mappings from /proc to find out the vDSO's mapping's size. That
generates extra RSP traffic when remote debugging. Particularly
annoying when the process's mappings grow linearly as more libraries
are mapped in, and we went through the trouble of making incremental
DSO list updates work against gdbserver (when the probes-based dynamic
linker interface is available).
The vsyscall/vDSO is mapped by the kernel when the process is
initially mapped in, and doesn't change throughout the process's
lifetime, so we can cache its address range.
Caching at this level brings GDB back to one and only one vsyscall
address range lookup per process.
Tested on x86_64 Fedora 20.
gdb/
2014-10-10 Pedro Alves <palves@redhat.com>
* linux-tdep.c: Include observer.h.
(linux_inferior_data): New global.
(struct linux_info): New structure.
(invalidate_linux_cache_inf, linux_inferior_data_cleanup)
(get_linux_inferior_data): New functions.
(linux_vsyscall_range): Rename to ...
(linux_vsyscall_range_raw): ... this.
(linux_vsyscall_range): New function; handles caching.
(_initialize_linux_tdep): Register linux_inferior_data. Install
inferior_exit and inferior_appeared observers.
With upstream glibc, GDB prints:
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
A bug's been filed for glibc a few years back:
http://sourceware.org/bugzilla/show_bug.cgi?id=13097
but it's still not resolved. It's not clear whether there's even
consensus that this is indeed a glibc bug. It would actually be nice
if GDB also listed the vDSO in the shared library list, but there are
some design considerations with that:
- the vDSO is mapped by the kernel, not userspace, therefore we
should load its symbols right from the process's start of life,
even before glibc / the userspace loader sets up the initial DSO
list. The program might even be using a custom loader or no
loader.
- that kind of hints at that solib.c should handle retrieving shared
library lists from more than one source, and that symfile-mem.c's
loading of the vDSO would be converted to load and relocate the
vDSO's bfd behind the target_so_ops interface.
- and then, once glibc links in the vDSO to its DSO list, we'd need
to either:
a) somehow hand over the vDSO from one target_so_ops to the other
b) simply keep hiding glibc's entry.
And then b) seems the simplest.
With that in mind, this patch simply discards the vDSO from glibc's
reported shared library list.
We can match the vDSO address range with the addresses found iterating
the dynamic linker list, to tell which dynamic linker entry is the
vDSO.
Tested on x86_64 Fedora 20.
gdb/
2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
PR symtab/14466
* solib-svr4.c (svr4_read_so_list): Rename to ...
(svr4_current_sos_1): ... this and change the function comment.
(svr4_current_sos): New function.
gdb/testsuite/
2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
PR symtab/14466
* gdb.base/vdso-warning.c: New file.
* gdb.base/vdso-warning.exp: New file.
We have a case in solib-svr4.c where we could reuse symfile-mem.c's
vDSO range lookup. Since symfile-mem.c is not present in all
configurations solib-svr4.c is, move that lookup to a gdbarch hook.
This has the minor (good) side effect that we stop even trying the
target_auxv_search lookup against targets that don't have a concept of
a vDSO, in case symfile-mem.c happens to be linked in the build
(--enable-targets=all).
Tested on x86_64 Fedora 20.
gdb/
2014-10-10 Pedro Alves <palves@redhat.com>
* arch-utils.c (default_vsyscall_range): New function.
* arch-utils.h (default_vsyscall_range): New declaration.
* gdbarch.sh (vsyscall_range): New hook.
* gdbarch.h, gdbarch.c: Regenerate.
* linux-tdep.c (linux_vsyscall_range): New function.
(linux_init_abi): Install linux_vsyscall_range as
vsyscall_range gdbarch hook.
* memrange.c (address_in_mem_range): New function.
* memrange.h (address_in_mem_range): New declaration.
* symfile-mem.c (find_vdso_size): Delete function.
(add_vsyscall_page): Use gdbarch_vsyscall_range.
