This has no behavior change in itself, but allows a future patch
to add a function to the Python API to look up symbols in the
static block.
gdb/ChangeLog:
2019-07-24 Christian Biesinger <cbiesinger@google.com>
* compile/compile-object-load.c (compile_object_load): Pass GLOBAL_SCOPE.
* solib-spu.c (spu_lookup_lib_symbol): Pass GLOBAL_SCOPE.
* solib-svr4.c (elf_lookup_lib_symbol): Pass GLOBAL_SCOPE.
* symtab.c (lookup_global_symbol_from_objfile): Add a scope parameter.
* symtab.h (lookup_global_symbol_from_objfile): Likewise.
When running gdb.objc/objcdecode.exp we get:
...
objcdecode.m: In function '-[Decode multipleDef]':
objcdecode.m:14:3: warning: incompatible implicit declaration of built-in \
function 'printf'
printf("method multipleDef\n");
^~~~~~
objcdecode.m:14:3: note: include '<stdio.h>' or provide a declaration of \
'printf'
...
Fix this in the three gdb.objc/*.m test-cases by including stdio.h.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-24 Tom de Vries <tdevries@suse.de>
PR testsuite/24807
* gdb.objc/basicclass.m: Include stdio.h.
* gdb.objc/nondebug.m: Same.
* gdb.objc/objcdecode.m: Same.
Revert
commit 8c728a9d93
Author: Martin Liska <mliska@suse.cz>
Date: Mon Jul 22 14:23:32 2019 +0200
Remove tests that test __gnu_lto_v1 symbol.
since outputs of these tests are used by later tests. Check the normal
symbol, foo, instead of __gnu_lto_v.*, which GCC stopped emitting after
r273662.
* testsuite/ld-plugin/lto-3r.d: Restored. Check foo instead
of __gnu_lto_v.*.
* testsuite/ld-plugin/lto-5r.d: Likewise.
* testsuite/ld-plugin/lto.exp: Run lto-3r and lto-5r tests.
When running gdb.base/infoline-reloc-main-from-zero.exp, I see:
...
Running gdb/testsuite/gdb.base/infoline-reloc-main-from-zero.exp ...
gdb compile failed, ld: infoline-reloc-main-from-zero: \
not enough room for program headers, try linking with -N
ld: final link failed: bad value
collect2: error: ld returned 1 exit status
UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: infoline-reloc-main-from-zero.exp
UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: failed to compile
...
Fix this by following the suggestion:
...
-set opts {debug "additional_flags=-nostdlib -emain -Wl,-Ttext=0x00"}
+set opts {debug "additional_flags=-nostdlib -emain -Wl,-Ttext=0x00 -Wl,-N"}
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-24 Tom de Vries <tdevries@suse.de>
PR testsuite/24612
* gdb.base/infoline-reloc-main-from-zero.exp: Add -Wl,-N to
additional_flags.
New instruction are added, and some of them are overlapping. Update
disassembler to correctly recognize them. Introduce nps400 option.
opcodes/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
* arc-dis.c (skip_this_opcode): Check also for 0x07 major opcodes,
and MPY class instructions.
(parse_option): Add nps400 option.
(print_arc_disassembler_options): Add nps400 info.
gas/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
* testsuite/gas/arc/nps400-6.d: Update test.
Add linker relaxation. The first relaxation added is converting
GOTPC32 to PCREL relocations. This relaxation doesn't change the size of
the binary.
bfd/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
* elf32-arc.c (bfd_get_32_me): New function.
(bfd_put_32_me): Likewise.
(arc_elf_relax_section): Likewise.
(bfd_elf32_bfd_relax_section): Define.
ld/testsuite/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
* ld-arc/relax-local-pic.d: New test.
* ld-arc/relax-local-pic.s: New file.
H8/300H general register name "ER0" - "ER7".
But gdb using "R0" - "R7".
This changes register name "ER0" - "ER7" in h8300h machine mode.
gdb/ChangeLog:
* h8300-tdep.c (h8300_register_name_common): New.
h8300_register_name): Use h8300_register_name_common.
(h8300s_register_name): Likewise.
(h8300sx_register_name): Likewise.
(h8300h_register_nam): New.
(h8300_gdbarch_init): Use h8300h_register_name in h8300h machine.
I missed some early exits from final_write_processing that mean
_bfd_elf_final_write_processing could be missed.
* elf-vxworks.c (elf_vxworks_final_write_processing): Don't return
early.
* elf32-arc.c (arc_elf_final_write_processing): Likewise.
* elf32-xtensa.c (elf_xtensa_final_write_processing): Likewise.
We currently have these FAILs:
...
FAIL: gdb.multi/tids.exp: two inferiors: info threads -1
FAIL: gdb.multi/tids.exp: two inferiors: info threads -$one
...
because we're expecting:
...
Invalid thread ID: -1
...
but instead we have:
...
Unrecognized option at: -1
...
This error message for info threads has changed since commit 54d6600669
'Make "info threads" use the gdb::option framework'.
Update the test accordingly.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-24 Tom de Vries <tdevries@suse.de>
PR testsuite/24831
* gdb.multi/tids.exp: Update error messages for info threads.
On openSUSE Leap 15.0, I get:
...
FAIL: gdb.base/info-types.exp: l=c: info types
FAIL: gdb.base/info-types.exp: l=c++: info types
...
because the info type command prints info for files info-types.c, stddef.h,
elf-init.c and init.c, while the regexp in the test-case expect only info for
info-types.c.
Fix this by extending the regexp.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-24 Tom de Vries <tdevries@suse.de>
* gdb.base/info-types.exp: Allow info types to print info for more than
one file.
PR 24818
* objdump.c (is_relocateable): Delete.
(load_specific_debug_section): Test the abfd for relocations
directly, rather than relying upon is_relocateable.
(dump_dwarf): Delete initlialization of is_relocateable.
When running multidictionary.exp in conjunction with:
...
$ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1))
...
we get:
...
Running gdb/testsuite/gdb.dwarf2/multidictionary.exp ...
ERROR: Couldn't load multidictionary into gdb.
=== gdb Summary ===
nr of unresolved testcases 1
...
The multidictionary test-case needs -readnow, and achieves this using:
...
gdb_spawn_with_cmdline_opts "-readnow"
gdb_load
...
but the initial gdb prompt is not read. Usually, the following gdb_load
command accidentally consumes that initial prompt (at the gdb_expect for the
kill command in gdb_file_cmd). But under high load, that doesn't happen and
we run into the error.
Fix this by consuming the initial gdb prompt after spawning gdb.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-23 Tom de Vries <tdevries@suse.de>
PR testsuite/24842
* gdb.dwarf2/multidictionary.exp: Consume initial prompt after
gdb_spawn_with_cmdline_opts.
GDB is not able to execute "step" command on function calls of Armv8-M cmse secure entry functions.
Everytime GNU linker come across definition of any cmse secure entry function in object file(s),
it creates two new instructions secure gateway (sg) and original branch destination (b.w),
place those two instructions in ".gnu.sgstubs" section of executable.
Any function calls to these cmse secure entry functions is re-directed through secure gateway (sg)
present in ".gnu.sgstubs" section.
Example:
Following is a function call to cmse secure entry function "foo":
...
bl xxxx <foo> --->(a)
...
<foo>
xxxx: push {r7, lr}
GNU linker on finding out "foo" is a cmse secure entry function, created sg and b.w instructions and
place them in ".gnu.sgstubs" section (marked by c).
The "bl" instruction (marked by a) which is a call to cmse secure entry function is modified by GNU linker
(as marked by b) and call flow is re-directly through secure gateway (sg) in ".gnu.sgstubs" section.
...
bl yyyy <foo> ---> (b)
...
section .gnu.sgstubs: ---> (c)
yyyy <foo>
yyyy: sg // secure gateway
b.w xxxx <__acle_se_foo> // original_branch_dest
...
0000xxxx <__acle_se_foo>
xxxx: push {r7, lr} ---> (d)
On invoking GDB, when the control is at "b" and we pass "step" command, the pc returns "yyyy"
(sg address) which is a trampoline and which does not exist in source code. So GDB jumps
to next line without jumping to "__acle_se_foo" (marked by d).
The above details are published on the Arm website [1], please refer to section 5.4 (Entry functions)
and section 3.4.4 (C level development flow of secure code).
[1] https://developer.arm.com/architectures/cpu-architecture/m-profile/docs/ecm0359818/latest/armv8-m-security-extensions-requirements-on-development-tools-engineering-specification
This patch fixes above problem by returning target pc "xxxx" to GDB on executing "step"
command at "b", so that the control jumps to "__acle_se_foo" (marked by d).
gdb/ChangeLog:
* arm-tdep.c (arm_skip_cmse_entry): New function.
(arm_is_sgstubs_section): New function.
(arm_skip_stub): Add call to arm_skip_cmse_entry function.
gdb/testsuite/ChangeLog:
* gdb.arch/arm-cmse-sgstubs.c: New test.
* gdb.arch/arm-cmse-sgstubs.exp: New file.
ld/ChangeLog:
2019-07-22 Martin Liska <mliska@suse.cz>
* testsuite/ld-plugin/lto-3r.d: Remove.
* testsuite/ld-plugin/lto-5r.d: Remove.
* testsuite/ld-plugin/lto.exp: Do not run lto-3r and lto-5r
tests.
When SHF_GNU_MBIND was added in the SHF_LOOS to SHF_HIOS range, it
should have required ELFOSABI_GNU since these flags are already in use
by other OSes. HPUX SHF_HP_TLS in fact has the same value. That
means no place in binutils should test SHF_GNU_MBIND without first
checking OSABI, and SHF_GNU_MBIND should not be set without also
setting OSABI. At least, that's the ideal, but the patch accepts
SHF_GNU_MBIND on ELFOSABI_NONE object files since gas didn't always
set OSABI. However, to reinforce the fact that SHF_GNU_MBIND isn't
proper without a non-zero OSABI, readelf will display the flag as
LOOS+0 if OSABI isn't set.
The clash with SHF_HP_TLS means that hppa64-linux either has that flag
on .tbss sections or supports GNU_MBIND, not both. (hppa64-linux
users, if there are any, may have noticed that GNU ld since 2017
mysteriously aligned their .tbss sections to a 4k boundary. That was
one consequence of SHF_HP_TLS being blindly interpreted as
SHF_GNU_MBIND.) Since it seems that binutils, gdb, gcc, glibc, and
the linux kernel don't care about SHF_HP_TLS I took that flag out of
.tbss for hppa64-linux.
bfd/
* elf-bfd.h (enum elf_gnu_osabi): Add elf_gnu_osabi_mbind.
* elf.c (_bfd_elf_make_section_from_shdr): Set elf_gnu_osabi_mbind.
(get_program_header_size): Formatting. Only test SH_GNU_MBIND
when elf_gnu_osabi_mbind is set.
(_bfd_elf_map_sections_to_segments): Likewise.
(_bfd_elf_init_private_section_data): Likewise.
(_bfd_elf_final_write_processing): Update comment.
* elf64-hppa.c (elf64_hppa_special_sections): Move .tbss entry.
(elf_backend_special_sections): Define without .tbss for linux.
binutils/
* readelf.c (get_parisc_segment_type): Split off hpux entries..
(get_ia64_segment_type): ..and these..
(get_hpux_segment_type): ..to here.
(get_segment_type): Condition GNU_MBIND on osabi. Use
get_hpux_segment_type.
(get_symbol_binding): Do not print UNIQUE for ELFOSABI_NONE.
(get_symbol_type): Do not print IFUNC for ELFOSABI_NONE.
gas/
* config/obj-elf.c (obj_elf_change_section): Don't emit a fatal
error for non-SHF_ALLOC SHF_GNU_MBIND here.
(obj_elf_parse_section_letters): Return SHF_GNU_MBIND in new
gnu_attr param.
(obj_elf_section): Adjust obj_elf_parse_section_letters call.
Formatting. Set SHF_GNU_MBIND and elf_osabi from gnu_attr.
Emit normal error for non-SHF_ALLOC SHF_GNU_MBIND and wrong osabi.
(obj_elf_type): Set elf_osabi for ifunc.
* testsuite/gas/elf/section12a.d: xfail msp430 and hpux.
* testsuite/gas/elf/section12b.d: Likewise.
* testsuite/gas/elf/section13.d: Likewise.
* testsuite/gas/elf/section13.l: Adjust expected error.
ld/
* emultempl/elf32.em (gld${EMULATION_NAME}_place_orphan): Condition
SHF_GNU_MBIND on osabi. Set output elf_gnu_osabi_mbind.
Also restore them somewhat closer to the original. They originally
failed on many targets, and a month later I "simplified" them as part
of a larger patch fixing other failing tests. That unfortunately lost
their main purpose, which was to test TLS layout.
* testsuite/ld-elf/size-1.d,
* testsuite/ld-elf/size-1.s,
* testsuite/ld-elf/size-1.t: New test.
* testsuite/ld-elf/size-2.d,
* testsuite/ld-elf/size-2.s,
* testsuite/ld-elf/size-2.t: New test.
* testsuite/ld-scripts/size-1.d,
* testsuite/ld-scripts/size-1.s,
* testsuite/ld-scripts/size-1.t,
* testsuite/ld-scripts/size-2.s,
* testsuite/ld-scripts/size-2.d,
* testsuite/ld-scripts/size-2.t,
* testsuite/ld-scripts/size.exp: Delete.
When running gdb.mi/mi-complete.exp in conjunction with:
...
$ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1))
...
we get less than 50% full passes:
...
$ for n in $(seq 1 100); do \
make V=1 -O check \
'RUNTESTFLAGS=gdb.mi/mi-complete.exp --target_board=unix'; \
done 2>&1 \
| grep "expected passes" | sort | uniq -c
45 # of expected passes 7
9 # of expected passes 8
46 # of expected passes 9
...
A diff between a passing and failing gdb.log shows this difference:
...
-&"set max-completions 1\n"
2-complete br
+&"set max-completions 1\n"
...
The problem is that the test-case issues the "set max-completion <n>" command,
and without waiting for the output issues a next command, and tries to parse
the results of both commands, expecting a specific interleaving of the various
output streams.
Fix the FAIL by waiting for the result of the "set max-completion <n>" command
before issuing another command.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-23 Tom de Vries <tdevries@suse.de>
PR testsuite/24711
* gdb.mi/mi-complete.exp: Wait for "set max-completions" result before
issuing next command.
In https://sourceware.org/ml/gdb-patches/2019-07/msg00509.html, Jan
pointed out that clang points out that
make_invisible_and_set_new_height self-assigns "height".
This patch fixes the bug by renaming the formal parameter.
gdb/ChangeLog
2019-07-22 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_win_info::make_invisible_and_set_new_height):
Don't self-assign.
The instructions that this change apply to are:
VQDMLADH, VQRDMLADH, VQDMLSDH, VQRDMLSDH
The updated documentation is here: https://static.docs.arm.com/ddi0553/bh/DDI0553B_h_armv8m_arm.pdf
Fixed this by removing the check for this warning from GAS as well as opcodes.
Added testcases to test that the warning is not generated for the instructions that have a 32-bit element size
and the same source and destination operand. Also fixed tests that would previously check for this warning.
gas * config/tc-arm.c (do_mve_vqdmladh): Remove check for UNPREDICTABLE.
* testsuite/gas/arm/mve-vqdmladh-bad.l: Remove tests.
* testsuite/gas/arm/mve-vqdmladh-bad.s: Remove tests.
* testsuite/gas/arm/mve-vqdmladh.d: New tests.
* testsuite/gas/arm/mve-vqdmladh.s: New tests.
* testsuite/gas/arm/mve-vqdmlsdh-bad.l: Remove tests.
* testsuite/gas/arm/mve-vqdmlsdh-bad.s: Remove tests.
* testsuite/gas/arm/mve-vqdmlsdh.d: New tests.
* testsuite/gas/arm/mve-vqdmlsdh.s: New tests.
opcodes * arm-dis.c (is_mve_unpredictable): Stop marking some MVE
instructions as UNPREDICTABLE.
Currently each language has a la_print_typedef method, this is only
used for the "info types" command.
The documentation for "info types" says:
Print a brief description of all types whose names match the regular
expression @var{regexp} (or all types in your program, if you supply
no argument).
However, if we consider this C code:
typedef struct {
int a;
} my_type;
Then currently with "info types" this will be printed like this:
3: typedef struct {
int a;
} my_type;
I see two problems with this, first the indentation is clearly broken,
second, if the struct contained more fields then it feels like the
actual type names could easily get lost in the noise.
Given that "info types" is about discovering type names, I think there
is an argument to be made that we should focus on giving _only_ the
briefest summary for "info types", and if the user wants to know more
they can take the type name and plug it into "ptype". As such, I
propose that a better output would be:
3: typedef struct {...} my_type;
The user understands that there is a type called `my_type`, and that
it's an alias for an anonymous structure type.
The change to achieve this turns out to be pretty simple, but only
effects languages that make use of c_print_typedef, which are C, C++,
asm, minimal, d, go, objc, and opencl. Other languages will for now
do whatever they used to do.
The patch to change how anonymous structs are displayed also changes
the display of anonymous enums, consider this code sample:
typedef enum {
AA, BB, CC
} anon_enum_t;
This used to be displayed like this:
3: typedef enum {AA, BB, CC} anon_enum_t;
Which will quickly become cluttered for enums with a large number of
values. The modified output looks like this:
3: typedef enum {...} anon_enum_t;
Again, the user can always make use of ptype if they want to see the
details of the anon_enum_t type.
It is worth pointing out that this change (to use {...}) only effects
anonymous structs and enums, named types don't change with this patch,
consider this code:
struct struct_t {
int i;
};
enum enum_t {
AA, BB, CC
};
The output from 'info types' remains unchanged, like this:
4: enum enum_t;
1: struct struct_t;
An additional area of interest is how C++ handles anonymous types used
within a typedef; enums are handled basically inline with how C
handles them, but structs (and classes) are slightly different. The
behaviour before the patch is different, and is unchanged by this
patch. Consider this code compiled for C++:
typedef struct {
int i;
} struct_t;
Both before and after this patch, this is show by 'info types' as:
3: typedef struct_t struct_t;
Unions are displayed similarly to structs in both C and C++, the
handling of anonymous unions changes for C in the same way that
it changes for anonymous structs.
I did look at ada, as this is the only language to actually have some
tests for "info types", however, as I understand it ada doesn't really
support typedefs, however, by forcing the language we can see what ada
would print. So, if we 'set language ada', then originally we printed
this:
3: record
a: int;
end record
Again the indentation is clearly broken, but we also have no mention
of the type name at all, which is odd, but understandable given the
lack of typedefs. If I make a similar change as I'm proposing for C,
then we now get this output:
3: record ... end record
Which is even less informative I think. However, the original output
_is_ tested for in gdb.ada/info_auto_lang.exp, and its not clear to me
if the change is a good one or not, so for now I have left this out.
gdb/ChangeLog:
* c-typeprint.c (c_print_typedef): Pass -1 instead of 0 to
type_print.
gdb/testsuite/ChangeLog:
* gdb.ada/info_auto_lang.exp: Update expected results.
* gdb.base/info-types.c: Add additional types to check.
* gdb.base/info-types.exp: Update expected results.
This commit makes two changes to the "info types" command:
First, only use typedef_print for printing typedefs, and use
type_print for printing non-typedef scalar (non-struct) types. The
result of this is the output for builtin types goes from this:
typedef double;
typedef float;
typedef int;
to this:
double;
float;
int;
which seems to make more sense.
Next GDB no longer matches msymbols as possible type names. When
looking for function symbols it makes sense to report matching
msymbols from the text sections, and for variables msymbols from the
data/bss sections, but when reporting types GDB would match msymbols
of type absolute. But I don't see why these are likely to indicate
type names. As such I've updated the msymbol matching lists in
symtab.c:search_symbols so that when searching in the TYPES_DOMAIN, we
never match any msymbols.
gdb/ChangeLog:
* symtab.c (search_symbols): Adjust msymbol matching type arrays
so that GDB doesn't match any msymbols when searching in the
TYPES_DOMAIN.
(print_symbol_info): Print using typedef_print or type_print based
on the type of the symbol. Add updated FIXME comment moved from...
(_initialize_symtab): ... move and update FIXME comment to above.
gdb/testsuite/ChangeLog:
* gdb.base/info-types.c: New file.
* gdb.base/info-types.exp: New file.
Adds a new -q flag to "info types" using the gdb::option framework.
This -q flag is similar to the -q flag already present for "info
variables" and "info functions".
gdb/ChangeLog:
* NEWS: Mention adding -q option to "info types".
* symtab.c (struct info_types_options): New struct.
(info_types_options_defs): New variable.
(make_info_types_options_def_group): New function.
(info_types_command): Use gdb::option framework to parse options.
(info_types_command_completer): New function.
(_initialize_symtab): Extend the help text on "info types" and
register command completer.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Add information about -q flag to "info
types".
gdb/ChangeLog:
2019-07-21 Christian Biesinger <cbiesinger@google.com>
* symtab.c (lookup_symbol_in_objfile_symtabs): Change int to block_enum.
(lookup_symbol_in_objfile): Change int to block_enum and add a
gdb_assert to make sure block_index is GLOBAL_BLOCK or STATIC_BLOCK.
The example in the documentation for the "python" command shows GDB
outputting instructions for how to terminate a sequence of python
commands entered from the command line. The documentation shows that
the following two lines are being output, though this does not occur
when actually using the "python" command from GDB:
Type python script
End with a line saying just "end".
While display of this text might be helpful, GDB has several other
commands which also use the "end" terminator that offer no such text.
Examples include the "if" and "while" commands. For example,
(gdb) if 1==1
>print "a"
>end
$1 = "a"
This seems similar to doing:
(gdb) python
>print 23
>end
23
If we decide that we want the "python" command to print such a message,
we should also adjust the behavior for other GDB commands which also use
"end" to terminate a command list. I.e, if this decision is made, the
"if" and "while" commands ought to also print similar messages.
So, for the moment anyway, this commit adjusts the documentation of the
python command to match its implementation.
This patch was taken from a larger body of work originating from the
Archer project. I haven't been able to determine its original author,
though I did find a commit log from Jan Kratochvil (in the Archer
repository) which suggests that the change had originally been made to
gdb.texinfo, but got inadvertently dropped when the python related
documentation was split out to python.texi.
gdb/doc/ChangeLog:
* python.texi (python command): Revise example to match
command behavior.
When making inferior function calls GDB sets up a dummy code region on
the stack, and places a breakpoint within that region. If the random
stack contents appear to be a compressed instruction then GDB will
place a compressed breakpoint, which can cause problems if the target
doesn't support compressed instructions.
This commit prevents this issue by writing a 4-byte nop instruction to
the dummy region at the time the region is allocated. With this nop
instruction in place, when we come to insert the breakpoint then an
uncompressed breakpoint will be used.
This is similar to other targets, for example mips.
gdb/ChangeLog:
* riscv-tdep.c (riscv_push_dummy_code): Write a 4-byte nop
instruction to the dummy code region.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-bp-infcall.c: New file.
* gdb.arch/riscv-bp-infcall.exp: New file.
