Add GAS and LD test cases for orphan REL HI16 relocation processing,
including verification of the addends produced as well as the warning
messages expected.
Due to the ordering used for the list of oustanding cached HI16 reloc
entries warnings for non-ELF links are issued in the reverse order
compared to one for ELF links. This is not considered a defect as all
the required warnings are produced in both cases, however separate
warning lists are required and included here for ELF and srec output.
Correct the addend being ignored for orphan REL HI16 relocations.
For assembly and non-ELF links `_bfd_mips_elf_hi16_reloc' is called from
`bfd_install_relocation' and `bfd_perform_relocation' respectively via
the respective howtos. It caches the relocation for later processing as
`_bfd_mips_elf_lo16_reloc' is called via the corresponding LO16 reloc's
howto, at which point both the HI16 and the LO16 parts are calculated
and installed.
If no matching LO16 relocation has been later encountered, then the
cached entry is never processed, with the outstanding cached entries
silently dropped at the conclusion of processing, resulting in zero
addend being used for the field relocated.
Dropping of the entries only happens in `_bfd_mips_elf_free_cached_info'
at the time the BFD is being successfully closed and section contents
long written to output. For non-ELF links dropping will also execute in
`_bfd_elf_mips_get_relocated_section_contents' via a separate piece of
code if the function has encountered an error.
Address the issues first by factoring out code to process outstanding
cached entries to `mips_elf_free_hi16_list' and then by making the
function actually install the relocations cached as required. This has
to happen before section contents have been written and therefore the
success path wires the function call to `bfd_finalize_section_relocs',
for assembly and `_bfd_elf_mips_get_relocated_section_contents' for
non-ELF links.
For housekeeping purposes the latter call will just drop cached entries
as it happens now in the case of an error, and likewise the call from
`_bfd_mips_elf_free_cached_info' is retained in case a fatal error in
the assembler prevents `bfd_finalize_section_relocs' from being called.
This also results in a warning being issued now about orphan REL HI16
relocations encountered in non-ELF links. Previously no such warning
was produced since the cached entries were dropped. For assembly we
expect the tool to have issued its own warning, so we process orphan
relocations silently if successful, but still issue a warning if an
error is returned.
We are careful in `mips_elf_free_hi16_list' to retain any incoming BFD
error as the function may be called under an error condition and if
there's another failure in processing at this stage we don't want to
clobber the original error.
Test cases will be added with a separate change.
Correct the addend being ignored for orphan REL HI16 relocations.
For ELF links `_bfd_mips_elf_relocate_section' handles relocation and
uses `mips_elf_add_lo16_rel_addend' to shift the incoming HI16 in-place
addend into its intended [31:16] bit positions and combine it with the
LO16 part. If no matching LO16 reloc has been found, then the function
returns early and consequently the incoming HI16 addend is not shifted
and remains in bits [0:15]. For final links any value of the symbol
referred is then added. Then the final value is shifted back into bits
[0:15] for installation into the field relocated. It is obviously wrong
as the original HI16 in-place addend has now been lost.
Fix the issue by shifting the incoming HI16 in-place addend before using
`mips_elf_next_relocation' to find the matching LO16 relocation. Then
upon early return from `mips_elf_add_lo16_rel_addend' the addend is in
the intended [31:16] bit positions already.
Test cases will be added with a separate change.
Use the warning callback for the orphan REL HI16 relocation warning just
as with any other linker relocation processing warnings, standardizing
the message format and providing source location where available.
Test cases will be added with a separate change.
Ever since commit 749b8d9d45 ("PATCH: ld/4208: `final link failed: Bad
value' when building Linux MIPS kernels."), which went in back in 2007,
<https://inbox.sourceware.org/binutils/20070320043504.GA7735@lucon.org/>,
we've been warning about unmatched HI16 REL relocations in the linker,
as it has been concluded in the discussion on PR ld/4208 that we have no
need to be forgiving about compiler bugs that lead to object files to be
made that are not compliant with the psABI.
However no corresponding update has ever been made to GAS, despite that
it's always helpful to issue a warning as early as possible in the build
process. In this particular case GAS also has more information to hand
as it always has the full original addend available that has been used
for both the high-part and the low-part relocation, while the linker has
to rely on the in-place value stored in the relocatable field by earlier
processing, which has necessarily been truncated. Therefore the linker
may miss cases where unrelated high-part and low-part relocations have
been put next to each other that had significantly different addends at
assembly time (small differences are deliberately permitted where they
are known not to affect any borrow from the high part).
Additionally GAS is able to point at the exact place in sources where
any offending orphan relocations have been used.
Update GAS to issue the warning then where applicable and remove an old
comment referring to GCC producing orphan HI16 relocations.
Test cases will be added with a separate change.
Update `bfd_finalize_section_relocs' to return status so that backends
can fail in this interface and propagate that to the respective callers.
Add suitable error reporting there. No failure cases in the existing
handlers though.
The `*_set_reloc' interface is to be called at the conclusion of section
relocation processing, however its name reflects a particular action to
take rather than the context of invocation. Implementation is already
backend-specific.
Rename the interface such as not to make its name artificially limit the
intended purpose. Update the callers and documentation accordingly. No
functional change.
Fold a separate call to `bfd_set_reloc' into SET_SECTION_RELOCS itself,
so that the GAS interface to this facility is contained in a single
invocation.
Currently both `write_relocs' and `obj_mach_o_reorder_section_relocs'
call `bfd_set_reloc', causing the function to be called twice by Mach-O
targets, such as `i386-darwin', once before target-specific processing
and again afterwards, which is at the very least fragile in terms of
assuming that any actions made by the function on the first invocation
won't interfere with the final intended result.
Set the macro by default to a plain call to `bfd_set_reloc', letting
backends override the macro, with the requirement now to factor in a
call to said function at the appropriate time. Backends can choose
whether to call `bfd_set_reloc' first (such as COFF), or last (such as
Mach-O), or at any other point in relation to their own additional
actions.
Update the COFF variant accordingly, moving it to a new function for a
better code structure, retaining functionality.
This is in preparation for `bfd_set_reloc' to return an error status.
In test-case gdb.base/tls-dlobj.exp we use breakpoints to step through the
executable. The breakpoints are used only once, but they are permanent, so we
end up with 11 breakpoints, 10 of which of the form $srcfile:$n.
The executable loads and unloads shared libraries, triggering solib events in
gdb, which will re-set the breakpoints.
Setting a breakpoint of the form $srcfile:$n triggers a filename search that
iterates over all CUs in all objfiles for which we have debuginfo.
In case glibc debuginfo is installed, and in case we have a slow gdb, for
instance because of building with -O0 and Address Sanitizer, this might become
noticeable.
While it's a good idea to try to speed up this search (see for instance
PR33781), measuring this speed is not the point of this test-case, so fix this
by making the breakpoints temporary.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
While playing with JIT reader I realized that it is not possible to set
a breakpoint on jitted function:
(gdb) b jit_function_stack_mangle
Function "jit_function_stack_mangle" not defined.
Make breakpoint pending on future shared library load? (y or [n])
The problem is that symbols for jitted functions (jit_function_stack_mangle
in the above example) are not added to jitted compunit's global block:
(gdb) maint print symtabs
...
Symtab for file at 0x55d6f8c186c0
Read from object file << JIT compiled code at 0x5555555592a0 >> (0x55d6f8cd4090)
Language: unknown
Line table:
line 1 at 0x7ffff7fbc000 (stmt)
line 0 at 0x7ffff7fbc001 (stmt)
Blockvector:
block #000, object at 0x55d6f8c188b0, 0 symbols in 0x7ffff7fbc000..0x7ffff7fbc011
block #001, object at 0x55d6f8c18910 under 0x55d6f8c188b0, 0 symbols in 0x7ffff7fbc000..0x7ffff7fbc011
block #002, object at 0x55d6f8c18730 under 0x55d6f8c18910, 0 symbols in 0x7ffff7fbc000..0x7ffff7fbc00a, function jit_function_stack_mangle
block #003, object at 0x55d6f8c187f0 under 0x55d6f8c18910, 0 symbols in 0x7ffff7fbc00a..0x7ffff7fbc011, function jit_function_add
This commit changes JIT reader to add jitted functions to the global
block:
...
Blockvector:
block #000, object at 0x55ed6665b180, 2 symbols in 0x7ffff7fbc000..0x7ffff7fbc011
void jit_function_stack_mangle(); block object 0x55ed6665b000, 0x7ffff7fbc000..0x7ffff7fbc00a
void jit_function_add(); block object 0x55ed6665b0c0, 0x7ffff7fbc00a..0x7ffff7fbc011
block #001, object at 0x55ed6665b230 under 0x55ed6665b180, 0 symbols in 0x7ffff7fbc000..0x7ffff7fbc011
block #002, object at 0x55ed6665b000 under 0x55ed6665b230, 0 symbols in 0x7ffff7fbc000..0x7ffff7fbc00a, function jit_function_stack_mangle
block #003, object at 0x55ed6665b0c0 under 0x55ed6665b230, 0 symbols in 0x7ffff7fbc00a..0x7ffff7fbc011, function jit_function_add
Approved-By: Tom Tromey <tom@tromey.com>
Type offsetT is either defined as signed 32-bit or 64-bit integer
depending on whether BFD64 is defined. Do not test for whether an
offsetT value exceeds INT32_MIN..INT32_MAX for !BFD64 32-bit offsetT
(or INT64_MIN..INT64_MAX for BFD64 64-bit offsetT). This is always
true and may result in a compile error when using compiler option
-Werror=type-limits, such as the one resolved with commit
6b8fb74a94 ("gas: sframe: do not test whether offsetT exceeds
INT64_MIN..INT64_MAX") for BFD64 64-bit offsetT:
../../binutils-gdb/gas/gen-sframe.c: In function ‘get_offset_size_in_bytes’:
../../binutils-gdb/gas/gen-sframe.c:213:45: error: comparison is always true due to limited range of data type [-Werror=type-limits]
213 | else if ((sizeof (offsetT) > 4) && (value <= INT64_MAX && value >= INT64_MIN))
| ^~
../../binutils-gdb/gas/gen-sframe.c:213:67: error: comparison is always true due to limited range of data type [-Werror=type-limits]
213 | else if ((sizeof (offsetT) > 4) && (value <= INT64_MAX && value >= INT64_MIN))
| ^~
Instead of testing for whether the value is in range of
INT8_MIN..INT8_MAX, INT16_MIN..INT16_MAX, or INT32_MIN..INT32_MAX,
test whether the value is unchanged when casted to int8_t, int16_t,
or int32_t. This also improves readability.
gas/
* gen-sframe.c (get_offset_size_in_bytes): Simplify. Do not
test whether !BFD64 32-bit offsetT exceeds INT32_MIN..INT32_MAX.
Fixes: 58008ed4e6 ("gas: sframe: use standard min/max integer constants")
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
A previous patch [1] enabled readline in Python in a GDB-specific way
and blocked the standard Python readline module to prevent conflicts
with GDB by adding a custom importer raising an exception for the readline
module.
This custom importer was written back in 2012 for old Python versions,
and does not seem to work anymore with Python 3.x. find_module() and
load_module() have been deprecated since Python 3.4, and the first one
has been removed since 3.12, and the second will be removed in 3.15.
The GDB testsuite does not cover this use case, and the removal of
find_module() was not detected by the testsuite. This issue is tracked
in bug 32473.
importlib.abc.MetaPathFinder:
find_module(fullname, path)
Deprecated since version 3.4: Use find_spec() instead.
Changed in version 3.10: Use of find_module() by the import
system now raises ImportWarning.
Changed in version 3.12: find_module() has been removed. Use
find_spec() instead.
find_spec(fullname, path, target=None)
New in version 3.4, as a replacement for find_module.
importlib.abc.Loader:
load_module(fullname):
Deprecated since version 3.4, will be removed in version 3.15
The recommended API for loading a module is exec_module()
(and create_module()).
This patch uses Patryk Sondej's approach detailed in bug 32473, but with
a slight variation regarding the finder insertion in sys.meta_path.
It also adds a new test to prevent future regression.
[1]: 037bbc8eea
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32473
Call _bfd_elf_section_from_bfd_section to get the sh_link value from
the section flag 'o' directive, which may point to special sections,
like SHN_ABS or SHN_COMM. Update readelf to print the special section
names in the sh_link field and replace "internal->sh_link > num" with
"internal->sh_link >= num".
bfd/
PR gas/33744
* elf.c (assign_section_numbers): Call
_bfd_elf_section_from_bfd_section to get the sh_link value.
binutils/
PR gas/33744
* readelf.c (special_defined_section_index): New.
(get_32bit_section_headers): Don't warn special section indexes
in the sh_link field.
(get_64bit_section_headers): Likewise.
(process_section_headers): Print special defined section names.
gas/
PR gas/33744
* testsuite/gas/elf/elf.exp: Run PR gas/33744 tests.
* testsuite/gas/elf/sh-link-abs-1.d: New file.
* testsuite/gas/elf/sh-link-abs-2.d: Likewise.
* testsuite/gas/elf/sh-link-abs-3-32.d: Likewise.
* testsuite/gas/elf/sh-link-abs-3-64.d: Likewise.
* testsuite/gas/elf/sh-link-abs-4-32.d: Likewise.
* testsuite/gas/elf/sh-link-abs-4-64.d: Likewise.
* testsuite/gas/elf/sh-link-abs.s: Likewise.
* testsuite/gas/elf/sh-link-common-1.d: Likewise.
* testsuite/gas/elf/sh-link-common-2.d: Likewise.
* testsuite/gas/elf/sh-link-common-3-32.d: Likewise.
* testsuite/gas/elf/sh-link-common-3-64.d: Likewise.
* testsuite/gas/elf/sh-link-common-4-32.d: Likewise.
* testsuite/gas/elf/sh-link-common-4-64.d: Likewise.
* testsuite/gas/elf/sh-link-common.s: Likewise.
* testsuite/gas/elf/sh-link-large-common-1.d: Likewise.
* testsuite/gas/elf/sh-link-large-common-2.d: Likewise.
* testsuite/gas/elf/sh-link-large-common-3.d: Likewise.
* testsuite/gas/elf/sh-link-large-common-4.d: Likewise.
* testsuite/gas/elf/sh-link-large-common.s: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
A value of type offsetT, which is either a signed 32-bit or 64-bit
integer, cannot exceed the range of INT64_MIN..INT64_MAX. This
resolves the following compile error:
../../binutils-gdb/gas/gen-sframe.c: In function ‘get_offset_size_in_bytes’:
../../binutils-gdb/gas/gen-sframe.c:213:45: error: comparison is always true due to limited range of data type [-Werror=type-limits]
213 | else if ((sizeof (offsetT) > 4) && (value <= INT64_MAX && value >= INT64_MIN))
| ^~
../../binutils-gdb/gas/gen-sframe.c:213:67: error: comparison is always true due to limited range of data type [-Werror=type-limits]
213 | else if ((sizeof (offsetT) > 4) && (value <= INT64_MAX && value >= INT64_MIN))
| ^~
Fixes: 58008ed4e6 ("gas: sframe: use standard min/max integer constants")
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Replace the use of custom VALUE_{8|16|32|64}BIT constant definitions
with the standard INT{8|16|32|64}_{MIN|MAX} ones from stdint.h.
Besides improving readability this also fixes the issue that the
smallest representable signed 8/16/32-bit integer value was
erroneously sized as the next larger integer type. For example
get_offset_size_in_bytes (INT8_MIN) returned 2 instead of 1, due
to INT8_MIN (= -128) != -VALUE_8BIT (= -127):
(gdb) call get_offset_size_in_bytes (-127)
$1 = 1
(gdb) call get_offset_size_in_bytes (-128)
$2 = 2
gas/
* gen-sframe.c (VALUE_8BIT, VALUE_16BIT, VALUE_32BIT,
VALUE_64BIT): Remove.
(get_offset_size_in_bytes): Use standard min/max integer
constants.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
The previous patch was all about address styling, but I spotted some
non-address styling that was missing. This patch covers those cases.
There's function name styling for the 'jump' command, and line number,
and function name styling for 'maint print symbols'.
Other than the extra styling, there should be no user visible changes
after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
I looked for the pattern 'gdb_puts (paddress (', these are places in
GDB where we are printing a target address without styling. I changed
most of what I found to print the address as styled.
I did leave a few unchanged in psymtab.c, these are all in maintenance
commands 'maint print psymbols', 'maint info psymtabs', and 'maint
check psymtabs'. None of these commands appear to print anything for
me (do we even use partial symtabs these days? I thought not) so I
didn't want to mess with commands that I couldn't test.
Other than the additional styling, there should be no user visible
changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
I noticed that the output of 'info frame' was not styled much; the
frame's filename is styled, as are the names of any frame local
variables. But there's lots of address and line number styling
missing.
When I started looking at the info_frame_command_core function though,
there were lots of coding standard changes that could be made too, so
while I was in the area I thought I'd make some coding standard
changes to the function:
+ Inlined local variable declarations.
+ Removed the 'caller_pc_p' local, and made 'caller_pc' a
std::optional<CORE_ADDR> instead.
+ Converted a local from 'int' to 'bool'.
+ Replaced NULL with nullptr.
+ Replaced calls to gdb_printf with gdb_puts when the thing to print
is a constant string.
+ Added { ... } around if/else bodies that are a single statement
AND a comment inline with GDB coding style.
+ Avoid treating pointers and integers as booleans in 'if'
conditions. Compare to nullptr and/or zero instead.
Other than the new styling, there should be no user visible changes
after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
Import the following commits from GCC as of r16-6728-g7c3584be8c8806:
07df546fb90 libiberty/testsuite: make test-pexecute's -t option a little more useful
0c775dcf3e7 libiberty: Make `objalloc_free' `free'-like WRT null pointer
The versioned symbol with the @@@ syntax is a special case. If the symbol
is not defined, 2 `@'s will be removed from the versioned_name. Otherwise,
1 `@' will be removed. But for malformed versioned symbols may not have
@@@:
.symver foo,foo@@@version1
.symver foo,foo@version2
Check @@@ before renaming the versioned symbol.
PR gas/33745
* config/obj-elf.c (elf_frob_file_before_adjust): Check @@@ before
renaming the versioned symbol.
* testsuite/gas/symver/symver.exp: Run symver17.
* testsuite/gas/symver/symver17.l: New file.
* testsuite/gas/symver/symver17.s: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
With test-case gdb.base/call-sc.exp I get:
DUPLICATE: gdb.base/call-sc.exp: tc: ptype; call-sc-tc (char)
DUPLICATE: gdb.base/call-sc.exp: ts: ptype; call-sc-ts (short)
DUPLICATE: gdb.base/call-sc.exp: ti: ptype; call-sc-ti (int)
...
Fix this by changing test name in testcase added in commit be90f3e2.
Tested on x86_64-linux.
Approved-By: Tom de Vries <tdevries@suse.de>
This fixes the following compile errors reported by Clang:
CC config/obj-elf-attr.o
../../gas/config/obj-elf-attr.c:64:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
64 | oav1_attr_info_init ()
| ^
| void
../../gas/config/obj-elf-attr.c:74:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
74 | oav1_attr_info_exit ()
| ^
| void
gas/
* config/obj-elf-attr.c (oav1_attr_info_init,
oav1_attr_info_exit): Explicitly code void parameter list.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
This changes symfile.c:symtab_fns to use a map rather than a vector,
letting us remove an otherwise extraneous type.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The aarch64 ABI states that long branch veneers may be added to
facilitate linking code that is beyond the range of a 26-bit call or
branch; but it requires that the target symbol be a function symbol.
Ensure that this latter condition is maintained by rejecting
relaxation of a static function symbol to it's section symbol.
Note that there should probably be a fix to the linker to enforce this
during link time. I've not done this for now because that might break
some existing object code that has been built with older versions of
gas. At some point we should revisit this.
This change also causes a small change in the LD testsuite: instead of
generating some veneers with the section name we now (correctly)
generate them using the name of the called function.
Update testsuite/gas/symver/symver15.l to expect:
Error: multiple versions [`foo@version2'|`foo@version1'] for symbol `foo'
* testsuite/gas/symver/symver15.l: Expect '|'.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Update or1k_apply_fix to handle all TLS relocations.
PR gas/33426
* config/tc-or1k.c (or1k_apply_fix): Handle all TLS relocations.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
When packing relative relocations, x86 linker may load the same symbol
table repeatedly, which can take a long time. On Intel Core i7-1195G7
with 32GB RAM, it takes more than 45 minutes to create an output with
-pie -z pack-relative-relocs from an input with 208025 code sections.
Cache the symbol table to reduce the link time to less than 2 seconds.
On the same machine, creating 3.1GB clang executable in LLVM 21.1.3 debug
build:
user 55.39 seconds
system 6.71 seconds
total 65.80 seconds
maximum set(GB) 10.43
page faults 2406941
PR ld/33765
* elfxx-x86.c (elf_x86_relative_reloc_record_add): Remove
keep_symbuf_p.
(_bfd_x86_elf_link_relax_section): Updated. Cache the symbol
table to avoid loading it again.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
With a gdb build with -O0 and Address Sanitizer and test-case
gdb.multi/sched-multi-add-inferior.exp, I get:
...
FAIL: $exp: target_type_1=extended-remote: target_type_2=extended-remote: \
continue to function1
FAIL: $exp: target_type_1=extended-remote: target_type_2=extended-remote: \
continue to function2
FAIL: $exp: target_type_1=native: target_type_2=extended-remote: \
continue to function1
FAIL: $exp: target_type_1=native: target_type_2=extended-remote: \
continue to function2
FAIL: $exp: target_type_1=native: target_type_2=native: continue to function1
FAIL: $exp: target_type_1=native: target_type_2=native: continue to function2
...
In more detail, for the target_type_1 == target_type_2 == native configuration,
we have:
...
(gdb) continue^M
Continuing.^M
[Switching to Thread 0x7ffff7cc02c0 (LWP 2514714)]^M
^M
Thread 2.1 "sched-multi-add" hit Breakpoint 4, main (...) at multi-target.c:94^M
94 function2 (); /* set break 2 here */^M
(gdb) FAIL: $exp: target_type_1=native: target_type_2=native: \
continue to function1
thread apply 2.1 set wait_for_gdb = 0^M
^M
Thread 2.1 (Thread 0x7ffff7cc02c0 (LWP 2514714) "sched-multi-add"):^M
(gdb) PASS: $exp: target_type_1=native: target_type_2=native: \
thread apply 2.1 set wait_for_gdb = 0
continue^M
Continuing.^M
[Switching to Thread 0x7ffff7cc02c0 (LWP 2514718)]^M
^M
Thread 3.1 "sched-multi-add" hit Breakpoint 3, main (...) at multi-target.c:93^M
93 function1 (); /* set break 1 here */^M
(gdb) FAIL: $exp: target_type_1=native: target_type_2=native: \
continue to function2
...
The situation is as follows:
- there are two inferiors
- due to "set schedule-multiple on", continue continues both inferiors
- after the first continue, the test-case expects the breakpoint on thread 3.1
to trigger
- instead, the breakpoint in thread 2.1 triggers
The mechanism by which this order is supposed to be guaranteed, is that thread
2.1 is blocked, and only unblocked after thread 3.1 hits its breakpoint:
...
# Unblock thread 2.1 and continue again. This time, thread 2.1
# will hit a breakpoint.
gdb_test "thread apply 2.1 set wait_for_gdb = 0" ".*"
...
However, thread 2.1 is never blocked.
Fix this by adding the missing:
...
gdb_test "thread apply 2.1 set wait_for_gdb = 1" ".*"
...
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33540
We look for stab sections for the sole purpose of emitting a warning if
we see one. Simplify this by using a boolean to indicate if we saw a
stab section or not. Simplify the search to just look for sections
starting with ".stab", it should be enough for this purpose.
Also, remove the make_scoped_restore that would overwrite the stab
section vector, I'm not sure why it's there. It seems to me like it
would cause the warning to never be shown.
Change-Id: I56323189ffdaa2d06a96d457cdd999b23efa5979
Approved-By: Tom Tromey <tom@tromey.com>
I noticed an unexpected behaviour difference when loading a core file
in GDB depending on whether the main executable can be accessed or not.
If GDB knows about the main executable, then symbols for unrelated
libraries (such as libc) are loaded. If GDB cannot find the main
executable, then they are not.
Here is a reproducer using the artifacts from
gdb.python/py-missing-objfile.exp. This test is ideal to reproduce the
problem, because it hides from GDB the executable and library used to
generate the core file.
In the "good" case, where we give an executable to GDB (in addition to
the core), we get a complete backtrace (assuming GDB can find debug symbols
for glibc):
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.python/py-missing-objfile/hidden/py-missing-objfile -c testsuite/outputs/gdb.python/py-missing-objfile/py-missing-objfile.core -ex bt -batch
...
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007fcbd0c98a13 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:89
#2 0x00007fcbd0c3e410 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007fcbd0c2557a in __GI_abort () at abort.c:77
#4 0x000055561659d152 in dump_core () at /home/sdarche/binutils-gdb/gdb/testsuite/gdb.python/py-missing-objfile.c:34
#5 0x000055561659d182 in main () at /home/sdarche/binutils-gdb/gdb/testsuite/gdb.python/py-missing-objfile.c:46
Or, if debug symbols for glibc aren't available, GDB at least tells us
from which .so each frame comes from:
#0 0x00007fcbd0c9894c in ?? () from /usr/lib/libc.so.6
#1 0x00007fcbd0c3e410 in raise () from /usr/lib/libc.so.6
#2 0x00007fcbd0c2557a in abort () from /usr/lib/libc.so.6
#3 0x000055561659d152 in dump_core () at /home/sdarche/binutils-gdb/gdb/testsuite/gdb.python/py-missing-objfile.c:34
#4 0x000055561659d182 in main () at /home/sdarche/binutils-gdb/gdb/testsuite/gdb.python/py-missing-objfile.c:46
If we omit passing the main executable to GDB (and GDB has no way to
find it, because the test moved it on purpose), we get:
$ ./gdb -nx -q --data-directory=data-directory -c testsuite/outputs/gdb.python/py-missing-objfile/py-missing-objfile.core -ex bt -batch
#0 0x00007fcbd0c9894c in ?? ()
#1 0x0000000000000000 in ?? ()
Upon investigating, the "normal" path to load associated sos is through
the post_create_inferior function in infcmd.c, which calls
solib_create_inferior_hook. The solib_ops in turn loads the symbols by
calling solib_add.
When loading a core file, the list of loaded shared libraries can be
found (and as we can see with `info sharedlibraries`, this is done
properly). However, the current control flow handling in
post_create_inferior does not ask the solib to load the symbols through
solib_create_inferior_hook if a main exec_bfd is not present.
The proposed change eliminates the if statement in the
post_create_inferior function.
This change may have side-effects on some solib_ops which may not check
if the current inferior has a valid exec_bfd().
This commit also modifies the gdb.python/py-missing-objfile.exp test,
providing a test case in which the main exec file is missing, but not
the shared library. This is a good way to confirm this fix works, as
the symbols from the shared library should be found even though the main
exec file is missing. The test cases also ask GDB to clean_restart to
ensure there is no leftover bfd or symbols.
Furthermore, the total number of calls to the missing objfiles handler
is 4 in the "all objfiles missing" test case instead of the
previous 3 :
- 2 for the mapped files (exec and so), in
core_target_build_file_mappings
- 1 for the core file exec, in locate_exec_from_corefile_build_id
- 1 for the missing so, in solib_map_sections
The changes in check_loaded_debug handle the case where no symbol exist
at all, and also when a symbol table exists (but the symbol cannot be
found)
Note: Some comments in some solib_ops (frv, dbst) seem to indicate that
solib_add should be called before solib_create_inferior_hook by
post_create_inferior, but this does not seem to be the case anymore.
Those comments might need to be updated.
Change-Id: I517ff85813c941215b19fa8540c77f755a0aca28
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Tested-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Loading a core file currently generates a warning when enabling `set
verbose on`:
$ ./gdb -nx -q --data-directory=data-directory a.out -ex "set verbose on" -ex "core core.151894" -batch
...
warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
The warning comes from infcmd.c:post_create_inferior() which initializes
the solib_ops. The latter is in charge of calling solib_add() in its
implementation of solib_ops::create_inferior_hook. The svr4_solib_ops
class, however, does not call solib_add (through enable_break) if the
inferior is not being executed.
This patch moves the call to solib_add() outside of the conditional
nested call. No user-visible change should be expected, except for fact
that the warning will no longer be shown.
Change-Id: I5488dc166fdc985669422a0f1c0c2f43158cd8c4
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The py-missing-objfile.exp test attempts to load a core file with
missing debug info and counts the number of times a python missing
objfile handler is called.
In one test case, the number of expected calls to the missing objfile
handler is two, but the test case misleadingly says three. This commit
fixes this typo.
Change-Id: I421143ebed392227f14918ea529eb0e9cbd98dda
Approved-By: Simon Marchi <simon.marchi@efficios.com>
