I see the fail on aarch64-linux,
(gdb) reverse-next
Breakpoint 2, callee () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c:26^M
26 myglob++; return 0; /* ARRIVED IN CALLEE */
(gdb) FAIL: gdb.reverse/next-reverse-bkpt-over-sr.exp: reverse-next over call trips user breakpoint at function entry
The test expects program stops at line 25, but program stops at line 26.
(gdb) maintenance info line-table
objfile: /scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/testsuite/outputs/gdb.reverse/next-reverse-bkpt-over-sr/next-reverse-bkpt-over-sr ((struct objfile *) 0x613000002880)
compunit_symtab: ((struct compunit_symtab *) 0x621000121760)
symtab: /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c ((struct symtab *) 0x6210001217e0)
linetable: ((struct linetable *) 0x6210001520d0):
INDEX LINE ADDRESS
0 25 0x0000000000400890
1 26 0x0000000000400890
2 27 0x00000000004008b0
(gdb) disassemble callee
Dump of assembler code for function callee:
0x0000000000400890 <+0>: adrp x0, 0x410000
0x0000000000400894 <+4>: add x0, x0, #0xcac
the line-table show that the first instruction of function callee is
mapped line 25 and 26. I am not sure the line-table is correct, but
it is not the point of this test. The goal of this test is to test
program hits the breakpoint on the first instruction of function after
'reverse-next', so I change this test to expect the breakpoint number
the program hits.
gdb/testsuite:
2016-04-07 Yao Qi <yao.qi@linaro.org>
* gdb.reverse/next-reverse-bkpt-over-sr.exp: Match the breakpoint
number instead of the comments on some line.
Some test fails in gdb.reverse/break-reverse.exp on arm-linux lead me
seeing the following error message,
continue^M
Continuing.^M
Cannot remove breakpoints because program is no longer writable.^M
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Further execution is probably impossible.^M
^M
Breakpoint 3, bar () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/break-reverse.c:22^M
22 xyz = 2; /* break in bar */^M
(gdb) PASS: gdb.reverse/break-reverse.exp: continue to breakpoint: bar backward
this is caused by two entries in record_full_breakpoints, and their addr
is the same, but in_target_beneath is different.
during the record, we do continue,
Continuing.
infrun: clear_proceed_status_thread (Thread 13772.13772)
infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: step-over queue now empty
infrun: resuming [Thread 13772.13772] for step-over
infrun: skipping breakpoint: stepping past insn at: 0x8620
Sending packet: $Z0,85f4,4#1d...Packet received: OK <----
.....
Sending packet: $vCont;c#a8...infrun: target_wait (-1.0.0, status) =
infrun: -1.0.0 [process -1],
infrun: status->kind = ignore
infrun: TARGET_WAITKIND_IGNORE
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: -1.0.0 [process -1],
infrun: status->kind = ignore
infrun: TARGET_WAITKIND_IGNORE
infrun: prepare_to_wait
Packet received: T05swbreak:;0b:9cf5ffbe;0d:9cf5ffbe;0f:f4850000;thread:p35cc.35cc;core:1;
Sending packet: $Z0,85f4,4#1d...Packet received: OK <-----
....
Sending packet: $z0,85f4,4#3d...Packet received: OK <-----
we can see breakpoint on 0x85f4 are inserted *twice*, but only removed
once. That is fine to remote target, because Z/z packets are
idempotent, but there is a leftover in record_full_breakpoints
in record-full target. The flow can be described as below,
record_full_breakpoints remote target
-----------------------------------------------------------------------
forward execution, continue, in_target_beneath 1 breakpoint inserted
insert breakpoints on 0x85f4 in_target_beneath 1
twice
program stops,
remove breakpoint on 0x85f4 in_target_beneath 1 breakpoint removed
reverse execution, continue, in_target_beneath 1 none is requested
insert breakpoints on 0x85f4, in_target_beneath 0
program stops,
remote breakpoint on 0x85f4, in_target_beneath 0 request to remove,
but GDBserver
doesn't know
now, the question is why breakoint on 0x85f4 is inserted twice? One
is the normal breakpoint, and the other is the single step breakpoint.
GDB inserts single step breakpoint to do single step. When program
stops at 0x85f4, both of them are set on 0x85f4, and GDB deletes
single step breakpoint, so in update_global_location_list, this
breakpoint location is no longer found, GDB call
force_breakpoint_reinsertion to mark it condition_updated, and insert
it again.
The reason force_breakpoint_reinsertion is called to update the
conditions in the target side, because the conditions may be
changed. My original fix is to not call force_breakpoint_reinsertion
if OLD_LOC->cond is NULL, but it is not correct if another location
on the same address has condition, GDB doesn't produce condition for
target side, but GDB should do.
Then, I change my mind back to make record-full handling breakpoint
idempotent, to align with remote target. Before insert a new entry
into record_full_breakpoints, look for existing one on the same
address first. I also add an assert on
"bp->in_target_beneath == in_target_beneath", to be safer.
gdb:
2016-04-07 Yao Qi <yao.qi@linaro.org>
* record-full.c (record_full_insert_breakpoint): Return
early if entry on the address is found in
record_full_breakpoints.
I notice that bp_tgt won't be fully initialized if to_insert_breakpoint
isn't called in record_full_insert_breakpoint, and bp_tgt->reqstd_address
is zero, so an entry is added to record_full_breakpoints, but its address
is zero, which is wrong. This patch is to call gdbarch_breakpoint_from_pc
in the else branch to set bp_tgt->reqstd_address and bp_tgt->placed_size.
gdb:
2016-04-07 Yao Qi <yao.qi@linaro.org>
* record-full.c (record_full_insert_breakpoint): Set
bp_tgt->reqstd_address and bp_tgt->placed_size.
When building with --enable-targets=all the target string is not set to
something that matches the pattern arc*-*, and so the script used to
decide if we should build big or little endian linker script currently
exits with an error.
This commit makes little endian linker script be the default, which will
be used when building for all targets, this matches the behaviour from
before I made the endianness switchable, when we only ever built little
endian linker scripts anyway.
ld/ChangeLog:
* emulparams/arc-endianness.sh: Make little endian default choice.
An upcoming commit will add a new arc instruction flag that uses
characters that have never appeared in an arc instruction flag before.
Currently the assembler is very conservative about which characters can
or cannot appear in an instruction flag.
This commit relaxes these constraints a little. After this commit all
alpha-numeric characters are now allowed into instruction flags. This
complete set is not required for the upcoming change, however, having
this slightly larger set does not impact the assemblers ability to
correctly parse input, but does make it easier to add new flag to the
instruction table.
gas/ChangeLog:
* config/tc-arc.c (tokenize_flags): Allow greater range of
characters into flag names.
The preprocess_operands function changes the incoming list of assembler
tokens based on the assumption that the first arc_operand found will be
the same instruction class as all of the arc_operands for the same
mnemonic.
Though this assumption is probably fine, removing this assumption, and
pushing the token change down into assemble_tokens makes the code no
more complex, and might even be easier to follow.
There should be no user visible changes after this commit.
gas/ChangeLog:
* config/tc-arc.c (find_opcode_match): Handle O_symbol case, add
new de_fault label.
(preprocess_operands): Delete.
(assemble_tokens): Remove call to preprocess_operands.
PR gas/19910
* config/tc-sparc.c (sparc_ip): Report an error if the expression
inside a %-macro could not be fully parsed.
* expr.c (integer_constant): Accept and ignore U suffixes to
integers.
(operand): When a missing closing parenthesis is encountered,
report the character that was found instead.
* testsuite/gas/mips/tls-ill.l: Update expected error message.
* testsuite/gas/sparc/pr19910-1.d: New test driver.
* testsuite/gas/sparc/pr19910-1.s: New test.
* testsuite/gas/sparc/pr19910-2.l: Expected error output.
* testsuite/gas/sparc/pr19910-2.s: New test.
* testsuite/gas/sparc/sparc.exp: Run the new tests.
This patch eliminates an error thrown when accessing the value of a
pointer to a structure where the pointer has been optimized out and
'set print object' is 'on'. The error shows up as the rather ugly
value of the pointer variable in Eclipse.
If 'set print object' is 'on', GDB tries to determine the actual
(derived) type of the object rather than the declared type, which
requires dereferencing the pointer, which in this cases throws an
error because the pointer has been optimized out.
The fix is to simply ignore the 'print object on' setting for
pointers or references to structures when they have been optimized
out. This means we just get the declared type instead of the actual
type, because in this case that's the best that we can do.
To implement the fix, value_optimized_out was modified so that it
no longer throws an error when it fails to fetch the specified
value. Instead, it just checks value->optimized_out. If we can't
definitively say that the value is optimized out, then we assume
it is not.
gdb/ChangeLog:
2016-04-06 Don Breazeal <donb@codesourcery.com>
* value.c (value_actual_type): Don't try to get rtti type
of the value if it has been optimized out.
(value_optimized_out): If a memory access error occurs,
just check vaue->optimized_out.
This patch implements a test that ensures that with "set print object
on", -var-create returns "<optimized out>" for an optimized out pointer
to structure, rather than throwing an error, while also ensuring that
any attempt to dereference the pointer *will* throw an error.
It uses the dwarf assembler to construct the appropriate debug info
to represent a pointer-to-struct in the program as optimized out,
and then accesses that pointer in various ways. The test uses both
the console interpreter and the MI interpreter.
gdb/testsuite/ChangeLog:
2016-04-06 Don Breazeal <donb@codesourcery.com>
* gdb.dwarf2/dw2-opt-structptr.c: New test program.
* gdb.dwarf2/dw2-opt-structptr.exp: New test script.
Following, commit
6e774b13c3 Make ftrace tests work with remote targets
the test gdb.threads/dlopen-libpthread.exp started to fail with:
ERROR: error copying "/home/emaisin/build/binutils-gdb/gdb/testsuite/gdb.threads/dlopen-libpthread.so": no such file or directory
This is because the library path is not computed using
standard_output_file, so we try to gdb_load_shlibs an unexisting file.
gdb/testsuite/ChangeLog:
* gdb.threads/dlopen-libpthread.exp: Set binfile_lib using
standard_output_file. Remove unused binfile variable.
It broke the compatibility with gdbserver-7.6 due to:
warning: remote target does not support file transfer, attempting to access files from local filesystem.
gdb/ChangeLog
2016-04-06 Jan Kratochvil <jan.kratochvil@redhat.com>
Revert the previous commit adding unknown_v_replies_ok.
With current FSF GDB HEAD and old FSF gdbserver I expected I could do:
gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234'
(supplying that unsupported qXfer:exec-file:read by "file")
But that does not work because:
Sending packet: $vFile:setfs:0#bf...Packet received: OK
Packet vFile:setfs (hostio-setfs) is supported
...
Sending packet: $vFile:setfs:104#24...Packet received: OK
"target:/root/redhat/threadit": could not open as an executable file: Invalid argument
GDB documentation says:
The valid responses to Host I/O packets are:
An empty response indicates that this operation is not recognized.
This "empty response" vs. "OK" was a bug in gdbserver < 7.7. It was fixed by:
commit e7f0d979dd
Author: Yao Qi <yao@codesourcery.com>
Date: Tue Dec 10 21:59:20 2013 +0800
Fix a bug in matching notifications.
Message-ID: <1386684626-11415-1-git-send-email-yao@codesourcery.com>
https://sourceware.org/ml/gdb-patches/2013-12/msg00373.html
2013-12-10 Yao Qi <yao@codesourcery.com>
* notif.c (handle_notif_ack): Return 0 if no notification
matches.
with unpatched old FSF gdbserver and patched FSF GDB HEAD:
gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234'
Sending packet: $vFile:setfs:0#bf...Packet received: OK
Packet vFile:setfs (hostio-setfs) is NOT supported
...
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00007ffff7ddbae0 0x00007ffff7df627a Yes (*) target:/lib64/ld-linux-x86-64.so.2
0x00007ffff7bc48a0 0x00007ffff7bcf514 Yes (*) target:/lib64/libpthread.so.0
gdb/ChangeLog
2016-04-06 Jan Kratochvil <jan.kratochvil@redhat.com>
* remote.c (struct remote_state): New field unknown_v_replies_ok.
(packet_config_support): Read it.
(remote_start_remote): Set it.
* config/tc-msp430.c (msp430_operands): Check for a NOP preceding
an EINT instruction. Warn/fix as necessary.
* testsuite/gas/msp430/bad.s: Add test of EINT without preceding NOP.
* testsuite/gas/msp430/bad.l: Update expected messages.
currently:
$ gdbserver-7.9 :1234 true &
$ gdb -q -ex 'target remote :1234' # that -q is not relevant here
Remote debugging using :1234
warning: Could not load vsyscall page because no executable was specified
try using the "file" command first.
0x00007ffff7ddcc80 in ?? ()
(gdb) b main
No symbol table is loaded. Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) _
Provide more suggestive message to use the "file" command.
gdb/ChangeLog
2016-04-06 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
* exec.c (exec_file_locate_attach): Print warning for unsupported
target_pid_to_exec_file.
* symfile-mem.c (add_vsyscall_page): Remove the "file" command
message part.
2016-04-06 Thomas Preud'homme <thomas.preudhomme@arm.com>
bfd/
* elf32-arm.c (elf32_arm_size_stubs): Move error_ret_free_local to be
a fall through from error_ret_free_internal. Free local_syms in
error_ret_free_local if allocated from bfd_elf_get_elf_syms ().
Starting with this commit:
commit e7ea3ec7c6
Author: Catalin Udma <catalin.udma@freescale.com>
Date: Mon Feb 29 16:16:19 2016 +0200
python: Use console format for output of gdb.execute command
the python script would use console format for gdb.execute output.
This patch fixes py-mi-objfile to expect the console format when is
checking for gdb.execute printing.
gdb/testsuite/ChangeLog:
2016-04-05 Catalin Udma <catalin.udma@freescale.com>
* gdb.python/py-mi-objfile-gdb.py: Use "list main" command.
* gdb.python/py-mi-objfile.exp: Match "list main" output
in console format.
Signed-off-by: Catalin Udma <catalin.udma@freescale.com>
In commit 6e774b13c3, I forgot to update this test.
gdb/testsuite/ChangeLog:
* gdb.arch/ftrace-insn-reloc.exp: Check for IPA basename instead of
absolute.
This aims to bring the linker for big-endian arc targets into line with
the linker for (the default) little endian arc targets.
The bulk of the changes are to extend the target pattern in the test
files from 'arc-*...' to 'arc*-*...' and so match both big and little
endian arc targets.
In the ld/emulparams/ directory the existing scripts checked for a
variable ARC_ENDIAN to switch between big and little endian targets,
however, this variable is never set up.
So, a new script snippet is introduced which sets up ARC_ENDIAN based on
the value of target, this snippet is then included from all of the
existing arc scripts.
The existing big-endian variants of all the scripts, which existed, but
were never used, are deleted in this commit.
ld/ChangeLog:
* emulparams/arc-endianness.sh: New file.
* emulparams/arcebelf.sh: Deleted.
* emulparams/arcebelf_prof.sh: Deleted.
* emulparams/arceblinux.sh: Deleted.
* emulparams/arceblinux_prof.sh: Deleted.
* emulparams/arcelf.sh: Include arc-endinness.sh.
* emulparams/arcelf_prof.sh: Include arc-endinness.sh.
* emulparams/arclinux.sh: Include arc-endinness.sh.
* emulparams/arclinux_prof.sh: Include arc-endinness.sh.
* emulparams/arcv2elf.sh: Include arc-endinness.sh.
* emulparams/arcv2elfx.sh: Include arc-endinness.sh.
* testsuite/ld-elf/compressed1d.d: Update pattern for big and
little endian arc targets.
* testsuite/ld-elf/eh-frame-hdr.d: Likewise.
* testsuite/ld-elf/group1.d: Likewise.
* testsuite/ld-elf/group3b.d: Likewise.
* testsuite/ld-elf/group8a.d: Likewise.
* testsuite/ld-elf/group8b.d: Likewise.
* testsuite/ld-elf/group9a.d: Likewise.
* testsuite/ld-elf/group9b.d: Likewise.
* testsuite/ld-elf/linkonce2.d: Likewise.
* testsuite/ld-elf/pr12851.d: Likewise.
* testsuite/ld-elf/pr12975.d: Likewise.
* testsuite/ld-elf/pr13177.d: Likewise.
* testsuite/ld-elf/pr13195.d: Likewise.
* testsuite/ld-elf/pr17615.d: Likewise.
* testsuite/ld-elf/pr19162.d: Likewise.
* testsuite/ld-elf/sec64k.exp: Likewise.
* testsuite/lib/ld-lib.exp: Likewise.
When we build a shared library for testing, it is built differently
whether it is meant for the local system or a remote one. When it is
for the local system, the library is built with no SONAME. So when the
executable is built, roughly in this way:
$ gcc testfile.c /path/to/library.so
the executable will contain an absolute reference to the library. For
example:
$ readelf -a testsuite/gdb.python/py-shared | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [/home/emaisin/build/binutils-gdb/gdb/testsuite/gdb.python/py-shared-sl.sl]
When testing is done remotely, the absolute path obviously doesn't work.
Therefore, we build the library with an SONAME:
$ readelf -a testsuite/gdb.python/py-shared-sl.sl | grep SONAME
0x000000000000000e (SONAME) Library soname: [py-shared-sl.sl]
which ends up in the executable's NEEDED field:
$ readelf -a testsuite/gdb.python/py-shared | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [py-shared-sl.sl]
The executable and the library are then uploaded side-by-side on the
remote system. To allow the dynamic linker to find the shared library,
we have to add the special RPATH value $ORIGIN, which tells it to search
in the executable's directory:
$ readelf -a testsuite/gdb.python/py-shared | grep ORIGIN
0x000000000000000f (RPATH) Library rpath: [$ORIGIN]
The problem with the IPA library is that it doesn't have an SONAME,
making it very difficult to do testing on a remote board. When a
test executable is linked with it, it contains an absolute reference to
the library path. Therefore, unless the paths on the target are the
same as on the build system, it won't work.
To make it possible for tests using the IPA library to run test on
remote boards, I suggest adding an SONAME to libinproctrace.so. I don't
think it should be a big problem for users. All the libraries installed
on my system have an SONAME, so it should be fine if libinproctrace.so
does too.
As a consequence, native testing does not work anymore, since
executables do not contain the absolute path to the library anymore. To
keep them working, we can have gdb_load_shlibs copy the library to the
test directory when testing natively. That's done by modifying
gdb_load_shlibs. We also have to add RPATH=$ORIGIN to executables, even
when testing natively.
I think it's a good change in general, as it reduces the differences
between testing a native and a remote target. To further reduce those
differences, we can also always build test shared libraries with an
SONAME.
ftrace.exp and ftrace-lock.exp need to be modified slightly. The code
checks that the IPA library is loaded using the absolute path on the
build machine. That obviously doesn't work if the test is done
remotely, as the path will be different. I changed the tests to only
search for the library basename (e.g. libinproctrace.so).
gdb/gdbserver/ChangeLog:
* Makefile.in ($(IPA_LIB)): Set SONAME of the IPA lib.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace-lock.exp: Check for IPA basename instead of
absolute.
* gdb.trace/ftrace.exp: Likewise.
* lib/gdb.exp (gdb_compile): Set rpath $ORIGIN for non-remote
targets as well.
(gdb_compile_shlib): Set SONAME for non-remote targets as well.
(gdb_load_shlibs): Copy libraries to test directory when testing
natively. Only set solib-search-path if testing remotely.
* lib/mi-support.exp (mi_load_shlibs): Likewise.
This patch removes gdb_download in favor of gdb_remote_download, since
they are very close in functionality. Also, in preparation for the
following patch about shared library handling during tests, it improves
gdb_remote_download so that it uses standard_output_file for any
destination board that is local, not only host.
If the destination board is remote, gdb_remote_download will use the
standard remote_download from DejaGnu, resulting in the file being
transferred on the remote system.
If the destination is local, gdb_remote_download will copy the file to
the standard test directory (found using standard_output_file). Tcl's
file copy seems to handle gracefully cases where the source file is the
same as the destination, so I don't think it's necessary to check for
that case ourselves, as a previous version of the patch did.
I'd prefer to keep the name gdb_download instead of gdb_remote_download,
since I don't like the fact that gdb_remote_download implies that the
destination is remote, when it's not always the case. However,
gdb_remote_download is used at many more places than gdb_download, so
it's easier to reuse that. Also, since it's a wrapper around DejaGnu's
remote_download, it might be better to keep that name. I don't know.
I ran the testsuite native, with native-gdbserver and with a
remote gdbserver, and didn't see any related failure.
gdb/testsuite/ChangeLog:
* gdb.base/jit-so.exp: Use gdb_remote_download instead of
gdb_download. Use it even if the target is not remote.
* gdb.base/jit.exp (compile_jit_test): Likewise.
* lib/gdb.exp (gdb_remote_download): Copy files to the standard
output directory if the destination board is local, otherwise use
the standard remote_download from DejaGnu.
(gdb_download): Remove.
(gdb_load_shlibs): Use gdb_remote_download instead of
gdb_download.
* lib/gdbserver-support.exp (gdbserver_download_current_prog):
Use gdb_remote_download instead of gdb_download. Use it even if
the target is not remote.
* lib/mi-support.exp (mi_load_shlibs): Use gdb_remote_download
instead of gdb_download.
The getauxval code was wrongly included in code area only compiled for
gdbserver. Move it to a #ifdef IN_PROCESS_AGENT area that already
contains lots of IPA-only code.
gdb/gdbserver/ChangeLog:
* tracepoint.c (getauxval): Move to #ifdef IN_PROCESS_AGENT.
bfd/
2016-04-05 Cupertino Miranda <cmiranda@synopsys.com>
* elf32-arc.c (name_for_global_symbol): Added assert to check for
symbol index.
(elf_arc_relocate_section): Added and changed asserts, validating
the synamic symbol index.
(elf_arc_finish_dynamic_symbol): Do not fill the dynamic
relocation if symbol has dynindx set to -1.
Always turn hidden and internal symbols which have a dynamic index into
local ones. This is required by the the ELF gABI[1]:
"A hidden symbol contained in a relocatable object must be either
removed or converted to STB_LOCAL binding by the link-editor when the
relocatable object is included in an executable file or shared object."
"An internal symbol contained in a relocatable object must be either
removed or converted to STB_LOCAL binding by the link-editor when the
relocatable object is included in an executable file or shared object."
The ELF linker usually respects this requirement, however in the case
where a dynamic symbol has been preallocated due to a reference of the
default export class aka visibility from the object being linked, and
then merged with a hidden or internal symbol definition from within the
same object, then the original export class is carried over to the
output dynamic symbol table, because while merging the generic ELF
linker only converts affected dynamic symbols to local when they are
defined or referenced by the object being linked and a dynamic object
involved in the link both at a time.
The dynamic symbol produced confuses then the dynamic loader at the run
time -- the hidden or internal export class is ignored and the symbol
follows preemption rules as with the default export class.
In the MIPS target it happens when `mips_elf_record_global_got_symbol'
creates a dynamic symbol when a call relocation is encountered.
Additionally if the undefined symbol referred by such a relocation does
specify the intended export class, then a local dynamic symbol is
created instead, which is harmless and allowed, but useless. Normally
no local dynamic symbols are created, except for a single dummy one at
the beginning.
Correct the problem by removing the extra check for a dynamic symbol
being defined or referenced by the object being linked and a dynamic
object involved in the link both at a time. The test cases included
cover the internal and hidden symbol cases, as well as a protected
symbol for a reference, the handling of which is unchanged by this fix.
Both cases described above are covered, that is where an internal or
hidden dynamic symbol is produced and where a local one is.
NB this change affects CRIS results where some symbols in the static
table produced in a final link are now converted from STV_HIDDEN to
STB_LOCAL. This happens whenever the `elf_backend_hide_symbol' handler
is called, so the affected symbols must have been chosen for entering
into the dynamic symbol table, except in these test cases no such symbol
table is produced. In fully linked binaries the static symbol table is
only used for debugging though, so such a change is fine.
References:
[1] "System V Application Binary Interface - DRAFT - 24 April 2001",
The Santa Cruz Operation, Inc., "Symbol Table",
<http://www.sco.com/developers/gabi/2001-04-24/ch4.symtab.html>
bfd/
PR ld/19908
* elflink.c (elf_link_add_object_symbols): Always turn hidden
and internal symbols which have a dynamic index into local
ones.
ld/
PR ld/19908
* testsuite/ld-cris/tls-e-20.d: Adjust for hidden symbol
handling fix.
* testsuite/ld-cris/tls-e-20a.d: Likewise.
* testsuite/ld-cris/tls-e-21.d: Likewise.
* testsuite/ld-cris/tls-e-23.d: Likewise.
* testsuite/ld-cris/tls-e-80.d: Likewise.
* testsuite/ld-cris/tls-gd-3h.d: Likewise.
* testsuite/ld-cris/tls-leie-19.d: Likewise.
* testsuite/ld-mips-elf/export-class-ref-lib.sd: New test.
* testsuite/ld-mips-elf/export-hidden-ref.sd: New test.
* testsuite/ld-mips-elf/export-internal-ref.sd: New test.
* testsuite/ld-mips-elf/export-protected-ref.sd: New test.
* testsuite/ld-mips-elf/export-class-ref-f0.s: New test source.
* testsuite/ld-mips-elf/export-class-ref-f1.s: New test source.
* testsuite/ld-mips-elf/export-class-ref-f2.s: New test source.
* testsuite/ld-mips-elf/mips-elf.exp: Run the new tests.
The libraries are never downloaded to the target for the first test
(test_insert_delete_modify), so the executable can't run properly.
I also added some with_test_prefix to help differentiate between the
different test case phases.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-breakpoint-changed.exp: Add some with_test_prefix.
(test_insert_delete_modify): Call mi_load_shlibs before trying to
run.
PR 19803
* emultempl/pe.em (change_undef): New function. Encapsulates
duplicated code in pe_fixup_stdcalls and adds the newly defined
sym to the gc root list.
(pe_fixup_stdcall): Use the new function.
* pe-dll.c (process_def_file_and_drectve); Add alias of exported
symbol to gc root list.
PR 19872
bfd * dwarf2.c (parse_comp_unit): Skip warning about unrecognised
version number if the version is zero.
bin * dwarf.c (display_debug_aranges): Skip warning about unrecognised
version number if the version is zero.
In tc-arc.h we redefine constants that are also defined in the
include/opcode/arc.h header file. The problem is that changing one
without changing the other resulting in strange crashes.
We could comment both locations to stress the importance of remembering
to update the other location too, or we could just include the
opcode/arc.h header file into the assembler.
Given that other targets include their opcode/ARCH.h header file, and
only having a single definition, where possible, is usually the safest
solution, that's what I switch too with this commit.
gas/ChangeLog:
* config/tc-arc.h: Include 'opcode/arc.h'.
(MAX_INSN_ARGS): Delete.
(MAX_INSN_FLGS): Delete.
