This patch fixes a build error due to a call to ppc_get_auxv that was
left over after linux_get_hwcap and linux_get_hwcap2 were introduced
in:
974c89e088 gdbserver: Add
linux_get_hwcap
Because the missing call fetched AT_PHDR and not AT_HWCAP,
linux_get_auxv is now visible.
This use also required ppc_get_auxv to return a status variable
indicating that the AT_PHDR entry was not found separately from the
actual value of of the auxv entry. Therefore, the new linux_get_auxv
function is changed to return a status variable and write the entry
value to a pointer passed as an argument.
Note that linux_get_hwcap and linux_get_hwcap2 still use the return
value as both an indicator of that the entry wasn't found and as the
actual value of the entry.
gdb/gdbserver/ChangeLog:
2019-04-05 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* linux-low.c (linux_get_auxv): Remove static. Return auxv entry
value in argument pointer, return 1 if the entry is found and 0
otherwise. Move comment.
(linux_get_hwcap, linux_get_hwcap2): Use modified linux_get_auxv.
* linux-low.h (linux_get_auxv): Declare.
* linux-ppc-low.c (is_elfv2_inferior): Use linux_get_auxv.
I noticed that "gdbserver --help" contains a few metasyntactic
variables that aren't in upper-case. This patch fixes them to conform
to the GNU standard.
gdb/gdbserver/ChangeLog
2019-04-05 Tom Tromey <tromey@adacore.com>
* server.c (gdbserver_usage): Use upper-case for metasyntactic
variables.
This introduces a new "type_stack" class, and moves all the parser
type stack handling to this class. Parsers that wish to use this
facility must now instantiate this class somehow. I chose this
approach because a minority of the existing parsers require this.
gdb/ChangeLog
2019-04-04 Tom Tromey <tom@tromey.com>
* type-stack.h: New file.
* type-stack.c: New file.
* parser-defs.h (enum type_pieces, union type_stack_elt): Move to
type-stack.h.
(insert_into_type_stack, insert_type, push_type, push_type_int)
(insert_type_address_space, pop_type, pop_type_int)
(pop_typelist, pop_type_stack, append_type_stack)
(push_type_stack, get_type_stack, push_typelist)
(follow_type_instance_flags, follow_types): Don't declare.
* parse.c (type_stack): Remove global.
(parse_exp_in_context): Update.
(insert_into_type_stack, insert_type, push_type, push_type_int)
(insert_type_address_space, pop_type, pop_type_int)
(pop_typelist, pop_type_stack, append_type_stack)
(push_type_stack, get_type_stack, push_typelist)
(follow_type_instance_flags, follow_types): Remove (moved to
type-stack.c).
* f-exp.y (type_stack): New global.
Update rules.
(push_kind_type, f_parse): Update.
* d-exp.y (type_stack): New global.
Update rules.
(d_parse): Update.
* c-exp.y (struct c_parse_state) <type_stack>: New member.
Update rules.
* Makefile.in (COMMON_SFILES): Add type-stack.c.
(HFILES_NO_SRCDIR): Add type-stack.h.
This removes the "paren_depth" global. In most cases, it is made into
a static global in a given parser. I consider this a slight
improvement, because it makes it clear that the variable isn't used
for communication between different modules of gdb. The one exception
is the Rust parser, which already incorporates all local state into a
transient object; in this case the parser depth is now a member.
gdb/ChangeLog
2019-04-04 Tom Tromey <tom@tromey.com>
* rust-exp.y (struct rust_parser) <paren_depth>: New member.
(rustyylex, rust_lex_test_init, rust_lex_test_one)
(rust_lex_test_sequence, rust_lex_test_push_back): Update.
* parser-defs.h (paren_depth): Don't declare.
* parse.c (paren_depth): Remove global.
(parse_exp_in_context): Update.
* p-exp.y (paren_depth): New global.
(pascal_parse): Initialize it.
* m2-exp.y (paren_depth): New global.
(m2_parse): Initialize it.
* go-exp.y (paren_depth): New global.
(go_parse): Initialize it.
* f-exp.y (paren_depth): New global.
(f_parse): Initialize it.
* d-exp.y (paren_depth): New global.
(d_parse): Initialize it.
* c-exp.y (paren_depth): New global.
(c_parse): Initialize it.
* ada-lex.l (paren_depth): New global.
(lexer_init): Initialize it.
This makes a new base class, expr_builder, for parser_state. This
separates the state needed to construct an expression from the state
needed by the parsers.
gdb/ChangeLog
2019-04-04 Tom Tromey <tom@tromey.com>
* gdbarch.h, gdbarch.c: Rebuild.
* gdbarch.sh (dtrace_parse_probe_argument): Change type.
* stap-probe.h:
(struct stap_parse_info): Replace "parser_state" with
"expr_builder".
* parser-defs.h (struct expr_builder): Rename from "parser_state".
(parser_state): New class.
* parse.c (expr_builder): Rename.
(expr_builder::release): Rename.
(write_exp_elt, write_exp_elt_opcode, write_exp_elt_sym)
(write_exp_elt_msym, write_exp_elt_block, write_exp_elt_objfile)
(write_exp_elt_longcst, write_exp_elt_floatcst)
(write_exp_elt_type, write_exp_elt_intern, write_exp_string)
(write_exp_string_vector, write_exp_bitstring)
(write_exp_msymbol, mark_struct_expression)
(write_dollar_variable)
(insert_type_address_space, increase_expout_size): Replace
"parser_state" with "expr_builder".
* dtrace-probe.c: Replace "parser_state" with "expr_builder".
* amd64-linux-tdep.c (amd64_dtrace_parse_probe_argument): Replace
"parser_state" with "expr_builder".
This changes parse_language into a method of parser_state. This patch
was written by a script.
gdb/ChangeLog
2019-04-04 Tom Tromey <tom@tromey.com>
* rust-exp.y: Replace "parse_language" with method call.
* p-exp.y:
(yylex): Replace "parse_language" with method call.
* m2-exp.y:
(yylex): Replace "parse_language" with method call.
* go-exp.y (classify_name): Replace "parse_language" with method
call.
* f-exp.y (yylex): Replace "parse_language" with method call.
* d-exp.y (lex_one_token): Replace "parse_language" with method
call.
* c-exp.y:
(lex_one_token, classify_name, yylex): Replace "parse_language"
with method call.
* ada-exp.y (find_primitive_type, type_char)
(type_system_address): Replace "parse_language" with method call.
All the real (not test) uses of parser_state pass 10 as the
"initial_size" parameter, and it seems to me that there's no real
reason to require callers to set this. This patch removes this
parameter.
gdb/ChangeLog
2019-04-04 Tom Tromey <tom@tromey.com>
* dtrace-probe.c (dtrace_probe::build_arg_exprs): Update.
* stap-probe.c (stap_parse_argument): Update.
* stap-probe.h (struct stap_parse_info) <stap_parse_info>: Remove
initial_size parameter.
* rust-exp.y (rust_lex_tests): Update.
* parse.c (parser_state): Update.
(parse_exp_in_context): Update.
* parser-defs.h (struct parser_state) <parser_state>: Remove
"initial_size" parameter.
increase_expout_size is only called from parse.c, and probably only
should be. This makes it "static". Tested by rebuilding.
gdb/ChangeLog
2019-04-04 Tom Tromey <tom@tromey.com>
* parser-defs.h (increase_expout_size): Don't declare.
* parse.c (increase_expout_size): Now static.
Adds a new test checking conditional branch BO values.
* testsuite/gas/ppc/bc.s,
* testsuite/gas/ppc/bcat.d,
* testsuite/gas/ppc/bcaterr.d,
* testsuite/gas/ppc/bcaterr.l,
* testsuite/gas/ppc/bcy.d,
* testsuite/gas/ppc/bcyerr.d,
* testsuite/gas/ppc/bcyerr.l: New tests.
* testsuite/gas/ppc/ppc.exp: Run them.
This patch fixes a problem with disassembly of branch instructions
for processors complying with PowerPC ISA versions prior to version
2.0, ie. those that use "y" bit branch taken hints. Many of the
extended bcctr and bclr mnemonics that should have disassembled with a
"-" suffix, ie. not taken, did not display the "-" due to the ordering
in powerpc_opcodes. I believe it's been that way from the original
85dcf36d72 commit of ppc-opc.c.
I've also added a BH field (optional) to a few opcodes. This gives
better disassembly in raw mode, showing the branch taken hint in the
mnemonic as is done for bc. It would be reasonable to add a BH
field to all bcctr, bclr, and bctar extended mnemonics but that runs
into a small difficulty: Currently we print all or none of the
optional operands. That means for example that "bgectr cr2" would
display as "bgectr cr2,0" if a BH field is added to bgectr.
* ppc-opc.c (XLBH_MASK): Subtract off BH field from BB_MASK.
(powerpc_opcodes): Reorder bcctr and bclr extended mnemonics
to favour printing of "-" branch hint when using the "y" bit.
Allow BH field on bc{ctr,lr,tar}{,l}{-,+}.
When an instruction has operands, the PowerPC disassembler prints
spaces after the opcode so as to line up operands. If the operands
are all optional and all default value, then no operands are printed,
leaving trailing spaces. This patch fixes that.
opcodes/
* ppc-dis.c (print_insn_powerpc): Delay printing spaces after
opcode until first operand is output.
gas/
* testsuite/gas/ppc/476.d: Remove trailing spaces.
* testsuite/gas/ppc/a2.d: Likewise.
* testsuite/gas/ppc/booke.d: Likewise.
* testsuite/gas/ppc/booke_xcoff.d: Likewise.
* testsuite/gas/ppc/e500.d: Likewise.
* testsuite/gas/ppc/e500mc.d: Likewise.
* testsuite/gas/ppc/e6500.d: Likewise.
* testsuite/gas/ppc/htm.d: Likewise.
* testsuite/gas/ppc/power6.d: Likewise.
* testsuite/gas/ppc/power8.d: Likewise.
* testsuite/gas/ppc/power9.d: Likewise.
* testsuite/gas/ppc/vle.d: Likewise.
ld/
* testsuite/ld-powerpc/tlsexe32.d: Remove trailing spaces.
* testsuite/ld-powerpc/tlsopt5.d: Likewise.
* testsuite/ld-powerpc/tlsopt5_32.d: Likewise.
Recent commit c29705b71a removed an incomplete
local implementation in favor of 'target_waitstatus_to_string' (thanks!), but
introduced a small typing error:
In file included from [...]/gdb/gnu-nat.c:24:0:
[...]/gdb/gnu-nat.c: In member function 'virtual ptid_t gnu_nat_target::wait(ptid_t, target_waitstatus*, int)':
[...]/gdb/gnu-nat.c:1652:43: error: cannot convert 'target_waitstatus**' to 'const target_waitstatus*' for argument '1' to 'std::__cxx11::string target_waitstatus_to_string(const target_waitstatus*)'
target_waitstatus_to_string (&status).c_str ());
^
[...]/gdb/gnu-nat.h:119:32: note: in definition of macro 'debug'
__FILE__ , __LINE__ , ##args); } while (0)
^~~~
[...]/gdb/gnu-nat.c:1650:3: note: in expansion of macro 'inf_debug'
inf_debug (inf, "returning ptid = %s, %s",
^~~~~~~~~
gdb/
* gnu-nat.c (gnu_nat_target::wait): Fix
target_waitstatus_to_string call.
Loop opcode relaxation that uses addi/addmi doesn't work well with other
relaxations that may cause code movement. Instead of encoding fixed loop
end offset in the relaxed sequence use l32r or a pair of const16 to load
loop end address. This way the address of the loop end gets a relocation
record and it gets updated appropriately.
gas/
2019-04-03 Max Filippov <jcmvbkbc@gmail.com>
* config/tc-xtensa.c (convert_frag_immed): Drop
convert_frag_immed_finish_loop invocation.
(convert_frag_immed_finish_loop): Drop declaration and
definition.
* config/xtensa-relax.c (widen_spec_list): Replace loop
widening that uses addi/addmi with widening that uses l32r
and const16.
Let's hope no one has section names starting with '/' in scripts. If
they do, this change to fix parsing of '/' in expressiongs will break
their project.
PR 24411
ldlex.l (SYMBOLNAMECHAR1): Don't match '/'.
(<EXPRESSION>"/DISCARD/"): New.
Underscore was specified twice in all these patterns, and backslash
twice in some. Flex warned about the $SYSROOT rule, which is covered
by earlier rules: "ldlex.l:386: warning, rule cannot be matched".
* ldlex.l: Formatting.
(CMDFILENAMECHAR, CMDFILENAMECHAR1): Delete.
(FILENAMECHAR1, SYMBOLNAMECHAR1, FILENAMECHAR, WILDCHAR),
(NOCFILENAMECHAR): Remove duplicate chars. Reorder.
(SYMBOLCHARN): Likewise. Rename to SYMBOLNAMECHAR.
(<INPUTLIST>"$SYSROOT"..): Delete rule.
This fixes a glib build failure reported in PR 24389. Using ld -b binary
creates an object file with no elf header flags set which has the wrong ABI
info for riscv64-linux. But the file also has no code sections, so I added
code borrowed from the arm port that only checks the ELF header ABI flags if
there is a code section.
bfd/
PR 24389
* elfnn-riscv.c (_bfd_riscv_elf_merge_private_bfd_data): Move read of
ELF header flags to after check for ELF object file. Loop through
sections looking for code sections, if none, then skip ABI checks.
If an convenience function is defined in python (or guile), then
currently this will not work in Fortran, instead the user is given
this message:
(gdb) set language fortran
(gdb) p $myfunc (3)
Cannot perform substring on this type
Compare this to C:
(gdb) set language c
(gdb) p $myfunc (3)
$1 = 1
After this patch we see the same behaviour in both C and Fortran.
I've extended the test to check that all languages can call the
convenience functions - only Fortran was broken.
When calling convenience functions in Fortran we don't need to perform
the same value preparation (passing by pointer) that we would for
calling a native function - passing the real value is fine.
gdb/ChangeLog:
* eval.c (evaluate_subexp_standard): Handle internal functions
during Fortran function call handling.
gdb/testsuite/ChangeLog:
* gdb.python/py-function.exp: Check calling helper function from
all languages.
* lib/gdb.exp (gdb_supported_languages): New proc.
Add two new internal functions $_cimag and $_creal that extract the
imaginary and real parts of a complex value.
These internal functions can take a complex value of any type 'float
complex', 'double complex', or 'long double complex' and return a
suitable floating point value 'float', 'double', or 'long double'.
So we can now do this:
(gdb) p z1
$1 = 1.5 + 4.5 * I
(gdb) p $_cimag (z1)
$4 = 4.5
(gdb) p $_creal (z1)
$4 = 1.5
The components of a complex value are not strictly named types in
DWARF, as the complex type is itself the base type. However, once we
are able to extract the components it makes sense to be able to ask
what the type of these components is and get a sensible answer back,
rather than the error we would currently get. Currently GDB says:
(gdb) ptype z1
type = complex double
(gdb) p $_cimag (z1)
$4 = 4.5
(gdb) ptype $
type = <invalid type code 9>
With the changes in dwarf2read.c, GDB now says:
(gdb) ptype z1
type = complex double
(gdb) p $_cimag (z1)
$4 = 4.5
(gdb) ptype $
type = double
Which seems to make more sense.
gdb/ChangeLog:
* NEWS: Mention new internal functions.
* dwarf2read.c (dwarf2_init_complex_target_type): New function.
(read_base_type): Use dwarf2_init_complex_target_type.
* value.c (creal_internal_fn): New function.
(cimag_internal_fn): New function.
(_initialize_values): Register new internal functions.
gdb/doc/ChangeLog:
* gdb.texinfo (Convenience Funs): Document '$_creal' and
'$_cimag'.
gdb/testsuite/ChangeLog:
* gdb.base/complex-parts.c: New file.
* gdb.base/complex-parts.exp: New file.
The test gdb.threads/watchthreads-reorder.exp verifies that the
'set debug infrun 1' debug output does not crash GDB.
Under high load, the test can still cause a GDB internal error (see details
below).
This patch fixes this crash, and improves/factorises some wait kind traces.
Tested on debian/amd64 + run one test with 'set debug infrun 1'.
Changes compared to the first version:
* Handles the suggestions of Kevin to trace the relevant elements
of the wait status (this is done by calling target_waitstatus_to_string).
* Some other changes to factorise wait status tracing.
Note that using target_waitstatus_to_string instead of the 'locally printed'
status kind strings means that debug trace that was using strings such as:
"EXITED" or "TARGET_WAITKIND_EXITED"
will now use what is printed by target_waitstatus_to_string e.g.
"exited".
gdb/ChangeLog
2019-04-01 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* infrun.c (stop_all_threads): If debug_infrun, always
trace the wait status after wait_one, using
target_waitstatus_to_string and target_pid_to_str.
(handle_inferior_event): Replace various trace of
wait status kind by a single trace.
* gdb/gnu-nat.c (gnu_nat_target::wait): Replace local
wait status kind image by target_waitstatus_to_string.
* target/waitstatus.c (target_waitstatus_to_string): Fix
obsolete comment.
(top-gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f3d54a0642a in __GI_abort () at abort.c:89
#2 0x0000555c24c60e66 in dump_core () at ../../fixleaks/gdb/utils.c:201
#3 0x0000555c24c63d49 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_list_tag __va_list_tag *) (problem=problem@entry=0x555c25338d40 <internal_error_problem>, file=<optimized out>, line=287,
fmt=<optimized out>, ap=<optimized out>) at ../../fixleaks/gdb/utils.c:411
#4 0x0000555c24c63eab in internal_verror (file=<optimized out>, line=<optimized out>, fmt=<optimized out>,
ap=<optimized out>) at ../../fixleaks/gdb/utils.c:436
#5 0x0000555c249e8c22 in internal_error (file=file@entry=0x555c24e0f2ad "../../fixleaks/gdb/inferior.c",
line=line@entry=287, fmt=<optimized out>) at ../../fixleaks/gdb/common/errors.c:55
#6 0x0000555c247d3f5c in find_inferior_pid (pid=<optimized out>) at ../../fixleaks/gdb/inferior.c:287
#7 0x0000555c24ad2248 in find_inferior_pid (pid=<optimized out>) at ../../fixleaks/gdb/inferior.c:302
#8 find_inferior_ptid (ptid=...) at ../../fixleaks/gdb/inferior.c:301
#9 0x0000555c24c35f25 in find_thread_ptid (ptid=...) at ../../fixleaks/gdb/thread.c:522
#10 0x0000555c24b0ab4d in thread_db_target::pid_to_str[abi:cxx11](ptid_t) (
this=0x555c2532e3e0 <the_thread_db_target>, ptid=...) at ../../fixleaks/gdb/linux-thread-db.c:1637
#11 0x0000555c24c2f420 in target_pid_to_str[abi:cxx11](ptid_t) (ptid=...) at ../../fixleaks/gdb/target.c:2083
#12 0x0000555c24ad9cab in stop_all_threads () at ../../fixleaks/gdb/infrun.c:4373
#13 0x0000555c24ada00f in stop_waiting (ecs=<optimized out>) at ../../fixleaks/gdb/infrun.c:7464
#14 0x0000555c24adc401 in process_event_stop_test (ecs=ecs@entry=0x7ffc9402d9d0) at ../../fixleaks/gdb/infrun.c:6181
...
(top-gdb) fr 12
#12 0x0000555c24ad9cab in stop_all_threads () at ../../fixleaks/gdb/infrun.c:4373
(top-gdb) p event_ptid
$5 = {m_pid = 25419, m_lwp = 25427, m_tid = 0}
(top-gdb) p ptid
$6 = {m_pid = 0, m_lwp = 0, m_tid = 0}
(top-gdb) p ws
$7 = {kind = TARGET_WAITKIND_THREAD_EXITED, value = {integer = 0, sig = GDB_SIGNAL_0, related_pid = {m_pid = 0,
m_lwp = 0, m_tid = 0}, execd_pathname = 0x0, syscall_number = 0}}
(top-gdb)
The gdb.log corresponding to the above crash is:
(gdb) PASS: gdb.threads/watchthreads-reorder.exp: reorder1: set debug infrun 1
continue
Continuing.
infrun: clear_proceed_status_thread (Thread 0x7ffff7fcfb40 (LWP 25419))
infrun: clear_proceed_status_thread (Thread 0x7ffff7310700 (LWP 25427))
infrun: clear_proceed_status_thread (Thread 0x7ffff6b0f700 (LWP 25428))
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming Thread 0x7ffff7fcfb40 (LWP 25419)
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff7fcfb40 (LWP 25419)] at 0x7ffff7344317
infrun: infrun_async(1)
infrun: prepare_to_wait
infrun: proceed: resuming Thread 0x7ffff7310700 (LWP 25427)
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff7310700 (LWP 25427)] at 0x5555555553d7
infrun: prepare_to_wait
infrun: proceed: resuming Thread 0x7ffff6b0f700 (LWP 25428)
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff6b0f700 (LWP 25428)] at 0x5555555554c8
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
Joining the threads.
[Thread 0x7ffff6b0f700 (LWP 25428) exited]
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: 25419.25419.0 [Thread 0x7ffff7fcfb40 (LWP 25419)],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x555555555e50
infrun: context switch
infrun: Switching context from Thread 0x7ffff6b0f700 (LWP 25428) to Thread 0x7ffff7fcfb40 (LWP 25419)
infrun: BPSTAT_WHAT_STOP_NOISY
infrun: stop_waiting
infrun: stop_all_threads
infrun: stop_all_threads, pass=0, iterations=0
infrun: Thread 0x7ffff7fcfb40 (LWP 25419) not executing
infrun: Thread 0x7ffff7310700 (LWP 25427) executing, need stop
[Thread 0x7ffff7310700 (LWP 25427) exited]
infrun: target_wait (-1.0.0, status) =
infrun: 25419.25427.0 [LWP 25427],
infrun: status->kind = thread exited, status = 0
infrun: infrun_async(0)
../../fixleaks/gdb/inferior.c:287: internal-error: inferior* find_inferior_pid(int): Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/watchthreads-reorder.exp: reorder1: continue to breakpoint: break-at-exit (GDB internal error)
Resyncing due to internal error.
n
infrun: infrun_async(1)
This is a bug, please report it. For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.
infrun: infrun_async(0)
../../fixleaks/gdb/inferior.c:287: internal-error: inferior* find_inferior_pid(int): Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y
add_partial_subprogram does not handle DW_AT_ranges, while the full
symtab reader does. This can lead to discrepancies where a function
is not put into a partial symtab, and so is not available to "break"
and the like -- but is available if the full symtab has somehow been
read.
This patch fixes the bug by arranging to read DW_AT_ranges when
reading partial DIEs.
This is PR symtab/23331.
The new test case is derived from dw2-ranges-func.exp, which is why I
kept the copyright dates.
gdb/ChangeLog
2019-04-01 Tom Tromey <tromey@adacore.com>
PR symtab/23331:
* dwarf2read.c (partial_die_info::read): Handle DW_AT_ranges.
gdb/testsuite/ChangeLog
2019-04-01 Tom Tromey <tromey@adacore.com>
PR symtab/23331:
* gdb.dwarf2/dw2-ranges-main.c: New file.
* gdb.dwarf2/dw2-ranges-psym.c: New file.
* gdb.dwarf2/dw2-ranges-psym.exp: New file.
When the user exits GDB, we might still have some allocated values in
the chain, which, in specific scenarios, can cause problems when GDB
attempts to destroy them in "quit_force". For example, see the bug
reported at:
https://bugzilla.redhat.com/show_bug.cgi?id=1690120
And the thread starting at:
https://sourceware.org/ml/gdb-patches/2019-03/msg00475.html
Message-ID: <87r2azkhmq.fsf@redhat.com>
In order to avoid that, and to be more aware of our allocated
resources, this commit implements a new function "finalize_values" and
calls it from inside "quit_force".
Tested by the BuildBot.
2019-04-01 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
* top.c (quit_force): Call 'finalize_values'.
* value.c (finalize_values): New function.
* value.h (finalize_values): Declare.
This patch adds a new framework to add architecture sensitive extensions, like
GCC does. This patch also implements all architecture extensions currently
available in GCC.
This framework works as follows. To enable architecture sensitive extensions
for a particular architecture, that architecture must contain an ARM_ARCH_OPT2
entry in the 'arm_archs' table. All fields here are the same as previous, with
the addition of a new extra field at the end to <name> it's extension table.
This <name>, corresponds to a <name>_ext_table of type 'struct arm_ext_table'.
This struct can be filled with three types of entries:
ARM_ADD (string <ext>, arm_feature_set <enable_bits>), which means +<ext> will
enable <enable_bits>
ARM_REMOVE (string <ext>, arm_feature_set <disable_bits>), which means
+no<ext> will disable <disable_bits>
ARM_EXT (string <ext>, arm_feature_set <enable_bits>, arm_feature_set
<disable_bits>), which means +<ext> will enable <enable_bits> and +no<ext>
will disable <disable_bits> (this is to be used instead of adding an
ARM_ADD and ARM_REMOVE for the same <ext>)
This patch does not disable the use of the old extensions, even if some of them
are duplicated in the new tables. This is a "in-between-step" as we may want to
deprecate the old table of extensions in later patches. For now, GAS will first
look for the +<ext> or +no<ext> in the new table and if no entry is found it
will continue searching in the old table, following old behaviour. If only an
ARM_ADD or an ARM_REMOVE is defined for <ext> and +no<ext> or +<ext> resp. is
used then it also continues to search the old table for it.
A couple of caveats:
- This patch does not enable the use of these architecture extensions with the
'.arch_extension' directive. This is future work that I will tend to later.
- This patch does not enable the use of these architecture extensions with the
-mcpu option. This is future work that I will tend to later.
- This patch does not change the current behaviour when combining an
architecture extension and using -mfpu on the command-line. The current
behaviour of GAS is to stage the union of feature bits enabled by both -march
and -mfpu. GCC behaves differently here, so this is something we may want to
revisit on a later date.
The str () function, called on a gdb.Value instance, produces a string
representation similar to what can be achieved with the print command,
but it doesn't allow to specify additional formatting settings, for
instance disabling pretty printers.
This patch introduces a new format_string () method to gdb.Value which
allows specifying more formatting options, thus giving access to more
features provided by the internal C function common_val_print ().
gdb/ChangeLog:
2019-04-01 Marco Barisione <mbarisione@undo.io>
Add gdb.Value.format_string ().
* python/py-value.c (copy_py_bool_obj):
(valpy_format_string): Add gdb.Value.format_string ().
* NEWS: Document the addition of gdb.Value.format_string ().
gdb/doc/ChangeLog:
2019-04-01 Marco Barisione <mbarisione@undo.io>
* python.texi (Values From Inferior): Document
gdb.Value.format_string ().
gdb/testsuite/ChangeLog:
2019-04-01 Marco Barisione <mbarisione@undo.io>
Test gdb.Value.format_string ().
* gdb.python/py-format-string.exp: New test.
* gdb.python/py-format-string.c: New file.
* gdb.python/py-format-string.py: New file.
PR 24402
* symtab.c (symtab_finalize): Init prev_addr to one less than
first symbol address, not one more. Correct test for symbols
with leading underscores.
I noticed that the help for "info addr" did not include a "usage"
line; and when adding it I went through and fixed a few minor issues
in printcmd.c:
* Added usage lines to all commands
* Updated the help text for some commands
* Changed some help to use upper case metasyntactic variables
* Removed some dead code
Regression tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-03-29 Tom Tromey <tromey@adacore.com>
* printcmd.c (_initialize_printcmd): Add usage lines. Update some
help text. Remove dead code.
gdb/testsuite/ChangeLog
2019-03-29 Tom Tromey <tromey@adacore.com>
* gdb.base/help.exp: Tighten apropos regexp.
This is the fortran part of the patch, including tests, which
are essentially unchanged from Siddhesh's original 2012 submission:
https://sourceware.org/ml/gdb-patches/2012-08/msg00562.html
There is, however, one large departure. In the above thread,
Jan pointed out problems with GCC debuginfo for -m32 builds
(filed usptream as gcc/54934). After investigating the issue,
I am dropping the hand-tweaked assembler source file to workaround
this case.
While I would normally do something to accommodate this, in
this case, given the ubiquity of 64-bit systems today (where
the tests pass) and the apparent lack of urgency on the compiler
side (by users), I don't think the additional complexity and
maintenance costs are worth it. It will be very routinely tested
on 64-bit systems. [For example, at Red Hat, we always
test -m64 and -m32 configurations for all GDB releases.]
gdb/ChangeLog:
From Siddhesh Poyarekar:
* f-lang.h (f77_get_upperbound): Return LONGEST.
(f77_get_lowerbound): Likewise.
* f-typeprint.c (f_type_print_varspec_suffix): Expand
UPPER_BOUND and LOWER_BOUND to LONGEST. Use plongest to format
print them.
(f_type_print_base): Expand UPPER_BOUND to LONGEST. Use
plongest to format print it.
* f-valprint.c (f77_get_lowerbound): Return LONGEST.
(f77_get_upperbound): Likewise.
(f77_get_dynamic_length_of_aggregate): Expand UPPER_BOUND,
LOWER_BOUND to LONGEST.
(f77_create_arrayprint_offset_tbl): Likewise.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-bounds.exp: New file.
* gdb.fortran/array-bounds.f90: New file.
