We have an issue in the MIPS backend, with the handling of undefined
hidden and internal weak symbols. References to such symbols are
supposed to resolve to 0 according to the ELF gABI[1]:
"Unresolved weak symbols have a zero value."
and the 64-bit MIPS psABI[2]:
"If a symbol with one of these [hidden or internal] attributes has no
definition within the executable/DSO being linked, then it must be
resolved to allocated space if common, resolved to zero if weak, or an
error reported otherwise."
however if a GOT relocation is used, then a local GOT entry is created
and used to satisfy the reference. Such an entry is then (in DSO and
PIE binaries) subject to the usual load-time relocation, which means a
non-zero value will be returned if the base address is non-zero. This
will defeat the usual run-time sequence like:
void a (void) __attribute__ ((visibility ("hidden"), weak));
void
x (void)
{
if (a)
a ();
}
This can be reproduced with this simple code:
$ cat libtest.c
extern int a __attribute__ ((visibility ("hidden"), weak));
int *
x (void)
{
return &a;
}
$ cat test.c
int *x (void);
int
main (void)
{
printf ("a: %p\n", x ());
return 0;
}
$ gcc -shared -fPIC -o libtest.so libtest.c
$ gcc -o test test.c -Wl,-rpath,$(pwd) libtest.so
$ ./test
a: 0x77184000
$
The usual approach targets take is making all the steps required to
assign a GOT entry for the symbol referred, and then leave its contents
at zero with no dynamic relocation attached, therefore ensuring that the
value does not change at load time. However this is not going to work
with the implicitly relocated GOT the MIPS psABI specifies[3]:
"The dynamic linker relocates the global offset table by first adding
the difference between the base where the shared object is loaded and
the value of the dynamic tag DT_MIPS_BASE_ADDRESS to all local global
offset table entries."
and we cannot therefore use the local GOT part.
And we cannot offhand use the global part either, as the symbol would
then have to be exported and possibly wrongly preempt symbols in other
modules involved in the dynamic load, because as per the ELF gABI[1] we
are not allowed to enter a hidden or internal symbol into the dynamic
symbol table (and then use its associated GOT entry):
"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."
and:
"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."
So we have to choose something else.
Our choice is further limited by the need for the reference associated
with the GOT relocation to stay within the signed 16-bit limit from the
GOT pointer base register, while being compliant with the ELF gABI and
the MIPS psABI. However as Alan Modra has observed[4] one possibility
is to edit (relax) the code such that the GOT reference is removed
altogether.
Based on these observations then modify MIPS BFD linker backend code to:
1. Interpret code associated with GOT relocations and relax the usual LW
or LD instructions into a corresponding immediate load operation that
places the value of 0 in the intended register, while leaving the GOT
entry allocated and initialized as usually.
2. Leave any other instructions associated with GOT relocations in place
and instead redirect the reference to a global GOT entry associated
with a special `__gnu_absolute_zero' symbol created for this purpose,
whose value is 0, SHN_ABS section marks it absolute, binding is
global and export class protected, ensuring that the locally provided
value is always used at load time, and that the value is not
relocated by the dynamic loader.
3. Adjust any high-part GOT relocation used, typically associated with
a LUI instruction, accordingly, so that run-time consistency is
maintained, either by resolving to the original entry if the
instruction associated with the corresponding low-part GOT relocation
has been relaxed to an immediate load (in which case the value loaded
with LUI will be overwritten), or by also redirecting the reference
to `__gnu_absolute_zero' to complete the GOT access sequence if that
symbol has been used.
4. Add a target `elf_backend_hide_symbol' hook, for the three MIPS ABIs,
which prevents the `__gnu_absolute_zero' symbol from being forced
local, to ensure that the redirection works and the symbol remains
global/protected with existing linker scripts unchanged.
5. Observing the issue with handling SHN_ABS symbols in the GNU dynamic
loader, covered by glibc PR 19818, set the EI_ABIVERSION field in the
ELF file header produced to 4 (ABI_ABSOLUTE) if `__gnu_absolute_zero'
symbol has been produced and the target configured indicates the GNU
operating system, so that broken versions of the GNU dynamic loader
gracefully reject the file in loading rather than going astray. Keep
EI_ABIVERSION at the original value for other operating systems or if
no `__gnu_absolute_zero' symbol has been made.
The name of the special `__gnu_absolute_zero' has no meaning other than
how a human reader can interpret it, as it is ignored in dynamic loading
in the handling of the scenarios concerned. This is because the symbol
resolves locally, and it's only the symbol's attributes that matter so
that the associated GOT entry remains unchanged at load time.
Therefore the name is somewhat arbitrary, observing however the need to
use the name space reserved for the system so that it does not conflict
with a possible user symbol, and hence the leading underscore, and also
the `gnu' infix to denote a GNU feature. Other implementations wishing
to address the problem in a similar way may choose a different name and
have the solution still work, possibly with a mixture of modules used in
a dynamic having symbols of different names provided, which will however
not interact with each other due to the protected export class.
The symbol can be referred explicitly, however the name is an internal
implementation detail rather than a part of the ABI, and therefore no
specific semantics is guaranteed.
One limitation of this change is that if `__gnu_absolute_zero' has been
already defined, then we do not wipe the old definition and all kinds of
odd behavior can result. This is however like with other symbols we
internally define, such as `_GLOBAL_OFFSET_TABLE_' or `__rld_map', and
therefore left as a possible future enhancement.
As an optimization the relaxation of LW and LD instructions to a load of
immediate zero is always made, even SVR4 PIC code for code that will end
up in a regular (non-PIE) executable, because there is a cache advantage
with the avoidance of a load from the GOT, even if it is otherwise
guaranteed to remain zero. It does not reliably happen though, due to a
symbol exportation issue affecting executables, covered by PR ld/21805.
One existing test case needs to be updated, as it triggers relaxation
introduced with this change and consequently linker output does not
match expectations anymore. As we want to keep the original issue
covered with the test case modify it then to use the LWL instruction in
place of LW, and adjust the output expected accordingly.
References:
[1] "System V Application Binary Interface - DRAFT - 19 October 2010",
The SCO Group, Section "Symbol Table",
<http://www.sco.com/developers/gabi/2012-12-31/ch4.symtab.html>
[2] "64-bit ELF Object File Specification, Draft Version 2.5", MIPS
Technologies / Silicon Graphics Computer Systems, Order Number
007-4658-001, Section 2.5 "Symbol Table", p. 22,
<http://techpubs.sgi.com/library/manuals/4000/007-4658-001/pdf/007-4658-001.pdf>
[3] "SYSTEM V APPLICATION BINARY INTERFACE, MIPS RISC Processor
Supplement, 3rd Edition", Section "Global Offset Table", p. 5-10,
<http://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf>
[4] "Undo dynamic symbol state after regular object sym type mismatch",
<https://sourceware.org/ml/binutils/2017-07/msg00265.html>
bfd/
PR ld/21375
* elfxx-mips.h (_bfd_mips_elf_hide_symbol): New prototype.
(_bfd_mips_elf_linker_flags): Update prototype.
* elf32-mips.c (elf_backend_hide_symbol): New macro.
* elf64-mips.c (elf_backend_hide_symbol): Likewise.
* elfn32-mips.c (elf_backend_hide_symbol): Likewise.
* elfxx-mips.c (mips_elf_link_hash_table): Add
`use_absolute_zero' and `gnu_target' members.
(mips_elf_record_global_got_symbol): Call
`_bfd_mips_elf_hide_symbol' rather than
`_bfd_elf_link_hash_hide_symbol'.
(mips_use_local_got_p): Return FALSE if the symbol is absolute.
(mips_elf_obtain_contents): Reorder function.
(mips_elf_nullify_got_load): New function.
(mips_elf_calculate_relocation): Add `contents' parameter.
Nullify GOT loads or if it is not possible, then redirect GOT
relocations to the `__gnu_absolute_zero' symbol, for references
that are supposed to resolve to zero.
(mips_elf_define_absolute_zero): New function.
(_bfd_mips_elf_check_relocs): Prepare for arrangements made in
`mips_elf_calculate_relocation' for references made via the GOT
that are supposed to resolve to zero.
(_bfd_mips_elf_hide_symbol): New function.
(_bfd_mips_elf_linker_flags): Add the `gnu_target' parameter,
set the `gnu_target' member of the MIPS hash table.
(MIPS_LIBC_ABI_ABSOLUTE): New enumeration constant.
(_bfd_mips_post_process_headers): Use it.
ld/
PR ld/21375
* emultempl/mipself.em: Set `gnu_target' according to ${target}.
(mips_create_output_section_statements): Update call to
`_bfd_mips_elf_linker_flags'.
* testsuite/ld-mips-elf/pr21334.s: Use LWL rather than LW.
* testsuite/ld-mips-elf/pr21334.dd: Update accordingly.
Move code used to store the contents of a relocated field in output into
a separate function, `mips_elf_store_contents', complementing existing
`mips_elf_obtain_contents'.
bfd/
* elfxx-mips.c (mips_elf_store_contents): New function...
(mips_elf_perform_relocation): ... factored out from here.
Fix an issue with the SEGMENT_START builtin function where its result is
absolute when taken from the default supplied, and section-relative when
taken from a `-T' command-line override. This is against documentation,
inconsistent and unexpected, and with PIE executables gives an incorrect
result with the `__executable_start' symbol.
Make the result of SEGMENT_START always section-relative then.
ld/
* ldexp.c (fold_binary): Always make the result of SEGMENT_START
section-relative.
* testsuite/ld-scripts/segment-start.d: New test.
* testsuite/ld-scripts/segment-start.ld: New test linker script.
* testsuite/ld-scripts/segment-start.s: New test source.
* testsuite/ld-scripts/script.exp: Run the new test.
Avoid a division by zero and thus a linker crash in SEGMENT_START script
builtin function handling, by not checking the value supplied with a
`-T' command-line override against the maximum page size if that has not
been set.
ld/
* ldexp.c (fold_binary): Check that `config.maxpagesize' is
non-zero before using it as a divisor.
Verify that -mevexwig=1 has no impact on non-WIG EVEX instruction encoding.
PR gas/23642
* testsuite/gas/i386/evex-wig2.d: New file.
* testsuite/gas/i386/evex-wig2.s: Likewise.
* testsuite/gas/i386/x86-64-evex-wig2.d: Likewise.
* testsuite/gas/i386/x86-64-evex-wig2.s: Likewise.
* testsuite/gas/i386/i386.exp: Run evex-wig2 and
x86-64-evex-wig2.
Add VEXWIG, defined as 3, to indicate that the VEX.W/EVEX.W bit is
ignored by such VEX/EVEX instructions, aka WIG instructions. Set
VexW=3 on VEX/EVEX WIG instructions. Update assembler to check
VEXWIG when setting the VEX.W bit.
gas/
PR gas/23642
* config/tc-i386.c (build_vex_prefix): Check VEXWIG when setting
the VEX.W bit.
(build_evex_prefix): Check VEXWIG when setting the EVEX.W bit.
opcodes/
PR gas/23642
* i386-opc.h (VEXWIG): New.
* i386-opc.tbl: Set VexW=3 on VEX/EVEX WIG instructions.
* i386-tbl.h: Regenerated.
Update x86 disassembler to ignore the EVEX.W bit in EVEX vcvt[u]si2s[sd]
instructions in 32-bit mode.
gas/
PR binutils/23655
* testsuite/gas/i386/evex.d: New file.
* testsuite/gas/i386/evex.s: Likewise.
* testsuite/gas/i386/i386.exp: Run evex.
opcodes/
PR binutils/23655
* i386-dis-evex.h (evex_table): Replace Eq with Edqa for
vcvtsi2ss%LQ, vcvtsi2sd%LQ, vcvtusi2ss%LQ and vcvtusi2sd%LQ.
* i386-dis.c (Edqa): New.
(dqa_mode): Likewise.
(intel_operand_size): Handle dqa_mode as m_mode.
(OP_E_register): Handle dqa_mode as dq_mode.
(OP_E_memory): Set shift for dqa_mode based on address_mode.
I noticed that call_function_by_hand_dummy has a block that only
exists to declare a variable, like:
{
int i;
for (i = ...0)
...
}
This patch removes the unnecessary and the extra indentation by moving
the declaration into the "for".
gdb/ChangeLog
2018-09-14 Tom Tromey <tom@tromey.com>
* infcall.c (call_function_by_hand_dummy): Remove unnecessary
block.
Define DIFF_EXPR_OK to Support PC relative diff relocation,
and add CKCORE_PCREL32 relocation process
bfd/
* elf32-csky.c (csky_elf_howto_table): Fill special_function of
R_CKCORE_PCREL32.
(csky_elf_relocate_section): Add R_CKCORE_PCREL32 process.
gas/
* config/tc-csky.c (md_apply_fix): Transmit
BFD_RELOC_32_PCREL to BFD_RELOC_CKCORE_PCREL32.
(tc_gen_reloc): Trasmit BFD_RELOC_CKCORE_ADDR32 to
BFD_RELOC_CKCORE_PCREL32 while pc-relative.
* config/tc-csky.h (DIFF_EXPR_OK): Define to enable PC relative
diff relocs.
I noticed that a variable in get_startup_shell is "static". However,
I couldn't see any reason it ought to be, so this removes the
"static".
gdb/ChangeLog
2018-09-14 Tom Tromey <tom@tromey.com>
* nat/fork-inferior.c (get_startup_shell): Remove "static".
dwarf2.c code reasonably assumes that debug info is local to a file,
an assumption now violated by gcc, resulting in "DWARF error: invalid
abstract instance DIE ref" or wrong details when attempting to print
linker error messages with file, function and line reported.
This is because find_abstract_instance is only prepared to handle
DW_FORM_ref_addr when the .debug_info section referenced is in the
current file. When that isn't the case, relocations to access another
file's .debug_info will typically be against a symbol defined at the
start of that .debug_info section, plus an addend. Since the dwarf2.c
code only considers the current file's debug info, that symbol will be
undefined, resolving to zero. In effect the ref_addr will wrongly
resolve to the current file's .debug_info.
This patch avoids the problem by treating relocations in debug
sections against undefined symbols in a similar manner to the way
relocations against symbols defined in discarded sections are
resolved. They result in a zero value (except in .debug_ranges)
regardless of the addend.
PR 23425
* reloc.c (bfd_generic_get_relocated_section_contents): Zero reloc
fields in debug sections when reloc is against an undefined symbol
and called from bfd_simple_get_relocated_section_contents or
similar.
* dwarf2.c (find_abstract_instance): Return true for zero offset
DW_FORM_ref_addr without returning values.
Just like other insns having byte and word forms, these can also make
use of the W modifier, which at the same time allows simplifying some
other code a little bit.
Simplfy gdb.exp by adding a function that will attempt to
compile a piece of code, then clean up, leaving the created
object.
gdb/testsuite
* lib/gdb.exp (gdb_simple_compile): Add proc.
(is_elf_target): Use gdb_simple_compile.
(skip_altivec_tests): Likewise.
(skip_vsx_tests): Likewise.
(skip_tsx_tests): Likewise.
(skip_btrace_tests): Likewise.
(skip_btrace_pt_tests): Likewise.
(gdb_can_simple_compile): Likewise.
(gdb_has_argv0): Likewise.
(gdb_target_symbol_prefix): Likewise.
(target_supports_scheduler_locking): Likewise.
I noticed that the TAGS target in gdb/testsuite/Makefile does not pick
up Tcl procs defined with proc_with_prefix or gdb_caching_proc. This
patch fixes this by updating the regexp.
Tested in Emacs.
gdb/testsuite/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
* Makefile.in (TAGS): Recognize proc_with_prefix and
gdb_caching_proc.
I noticed that infpy_thread_from_thread_handle is not static, but
should be. This patch changes it.
gdb/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
* python/py-inferior.c (infpy_thread_from_thread_handle): Now
static.
This removes a cleanup from try_open_exec_file, using std::string to
manage the storage instead.
gdb/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
* exec.c (try_open_exec_file): Use std::string.
This changes gdb_bfd_errmsg to return a std::string, removing a
cleanup. This approach may be slightly less efficient than the
previous code, but I don't believe this is very important in this
situation.
gdb/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
* utils.h (gdb_bfd_errmsg): Return std::string.
* exec.c (exec_file_attach): Update.
* compile/compile-object-load.c (compile_object_load): Update.
* utils.c (gdb_bfd_errmsg): Return std::string.
This removes the last remaining cleanup from procfs.c, replacing it
with a unique_ptr specialization.
gdb/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
* procfs.c (struct procinfo_deleter): New.
(procinfo_up): New typedef.
(do_destroy_procinfo_cleanup): Remove.
(procfs_target::info_proc): Use procinfo_up. Remove cleanups.
This removes a cleanup from add_path, replacing it with a use of
gdb::unique_xmalloc_ptr. Note that this declaration had to be hoisted
somewhat, to avoid inteference from the "goto"s in this function.
gdb/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
* source.c (add_path): Use gdb::unique_xmalloc_ptr.
The code implementing gdb.objfiles() returns a list of objfiles for the
current program space (the program space of the selected inferior). The
documentation for the gdb.objfiles() Python method, however, states:
Return a sequence of all the objfiles current known to GDB.
That sounds wrong to me. I tried to phrase to be more precise.
gdb/doc/ChangeLog:
* python.texi (Objfiles In Python): Update gdb.objfiles() doc.
This patch adds an objfiles method to the Progspace object, which
returns a sequence of the objfiles associated to that program space. I
chose a method rather than a property for symmetry with gdb.objfiles().
gdb/ChangeLog:
* python/py-progspace.c (PSPY_REQUIRE_VALID): New macro.
(pspy_get_objfiles): New function.
(progspace_object_methods): New.
(pspace_object_type): Add tp_methods callback.
* python/python-internal.h (build_objfiles_list): New
declaration.
* python/python.c (build_objfiles_list): New function.
(gdbpy_objfiles): Implement using build_objfiles_list.
* NEWS: Mention the Progspace.objfiles method.
gdb/doc/ChangeLog:
* python.texi (Program Spaces In Python): Document the
Progspace.objfiles method.
(Objfiles In Python): Mention that gdb.objfiles() is identical
to gdb.selected_inferior().progspace.objfiles().
gdb/testsuite/ChangeLog:
* gdb.python/py-progspace.exp: Test the Progspace.objfiles
method.
This patch adds a progspace property to the gdb.Inferior type, which
allows getting the gdb.Progspace object associated to that inferior.
In conjunction with the following patch, this will allow scripts iterate
on objfiles associated with a particular inferior.
gdb/ChangeLog:
* python/py-inferior.c (infpy_get_progspace): New function.
(inferior_object_getset): Add progspace property.
* NEWS: Mention the new property.
gdb/doc/ChangeLog:
* python.texi (Inferiors In Python): Document
Inferior.progspace.
(Program Spaces In Python): Document that
gdb.current_progspace() is the same as
gdb.selected_inferior().progspace.
gdb/testsuite/ChangeLog:
* gdb.python/py-inferior.exp: Add tests for Inferior.progspace
and a few other Inferior properties when the Inferior is no
longer valid.
I noticed a spot in rust-lang.c where the placeholder "foo" was used
instead of the actual field name. This patch fixes the bug.
gdb/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
PR rust/23650:
* rust-lang.c (rust_evaluate_subexp): Use field name, not "foo".
gdb/testsuite/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
PR rust/23650:
* gdb.rust/simple.exp: Add test for enum field access error.
While testing my Rust compiler patch to fix the DWARF representation
of Rust enums (https://github.com/rust-lang/rust/pull/54004), I found
a gdb crash coming from one of the Rust test cases.
The bug here is that the new variant support in gdb does not handle
the case where there are no variants in the enum.
This patch fixes the problem in a straightforward way. Note that the
new tests are somewhat lax because I did not want to try to fully fix
this corner case for older compilers. If you think that's
unacceptable, let meknow.
Tested on x86-64 Fedora 28 using several versions of the Rust
compiler. I intend to push this to the 8.2 branch as well.
gdb/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
PR rust/23626:
* rust-lang.c (rust_enum_variant): Now static.
(rust_empty_enum_p): New function.
(rust_print_enum, rust_evaluate_subexp, rust_print_struct_def):
Handle empty enum.
gdb/testsuite/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
PR rust/23626:
* gdb.rust/simple.rs (EmptyEnum): New type.
(main): Use it.
* gdb.rust/simple.exp (test_one_slice): Add empty enum test.
On commit:
commit 5a6996172e
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date: Mon Aug 6 16:05:16 2018 +0200
Update dg-extract-results.* from gcc
dg-extract-results.sh was moved from the "gdb/contrib/" directory to
the toplevel "contrib/" directory. However, src-release.sh was not
updated in order to include "contrib/" in the tarball release of GDB.
This makes it very inconvenient to run and analyze the GDB testsuite
results. This commit adds "contrib/" to the list of support
directories that are included in each GDB release.
ChangeLog:
2018-09-12 Sergio Durigan Junior <sergiodj@redhat.com>
* src-release.sh (GDB_SUPPORT_DIRS): Add "contrib".
Printing a GDB Python object is notoriously not helpful:
>>> print(gdb.selected_inferior())
<gdb.Inferior object at 0x7fea59aed198>
>>> print(gdb.objfiles())
[<gdb.Objfile object at 0x7fea59b57c90>]
This makes printing debug traces more difficult than it should be. This
patch provides some repr() implementation for these two types (more to
come if people agree with the idea, but I want to test the water first).
Here's the same example as above, but with this patch:
>>> print(gdb.selected_inferior())
<gdb.Inferior num=1>
>>> print(gdb.objfiles())
[<gdb.Objfile filename=/home/emaisin/build/binutils-gdb-gcc-git/gdb/test>]
I implemented repr rather than str, because when printing a list (or
another container I suppose), Python calls the repr method of the
elements. This is useful when printing a list of inferiors or objfiles.
The print(gdb.objfiles()) above would not have worked if I had
implemented str.
I found this post useful to understand the difference between repr and
str:
https://stackoverflow.com/questions/1436703/difference-between-str-and-repr
gdb/ChangeLog:
* python/py-inferior.c (infpy_repr): New.
(inferior_object_type): Register infpy_repr.
* python/py-objfile.c (objfpy_repr): New.
(objfile_object_type): Register objfpy_repr.
gdb/testsuite/ChangeLog:
* gdb.python/py-inferior.exp: Test repr() of gdb.Inferior.
* gdb.python/py-objfile.exp: Test repr() of gdb.Objfile.
* gdb.python/py-symtab.exp: Update test printing an objfile.
gdb/doc/ChangeLog:
* python.texi (Basic Python): Mention the string representation
of GDB Python objects.
When encoding VEX, we can swap destination and source only if there are
more than 1 register operand.
* config/tc-i386.c (build_vex_prefix): Swap destination and
source only if there are more than 1 register operand.
