I noticed after commit 8ad93045ed, "ld, gold: remove support for -z
bndplt (MPX prefix)", that some of my builds were failing with
eelf_x86_64_haiku.c:650:9: error: no member named 'bndplt' in 'struct elf_linker_x86_params'
params.bndplt = true;
~~~~~~ ^
* emulparams/aarch64haiku.sh: Use "source_sh" rather than ".".
* emulparams/armelf_haiku.sh: Likewise.
* emulparams/elf32ppchaiku.sh: Likewise.
* emulparams/elf_mipsel_haiku.sh: Likewise.
* emulparams/elf_x86_64_haiku.sh: Likewise.
After the previous commit converted symbol-lookup debug to use the new
debug scheme, this commit adds SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT.
The previous commit didn't add SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT
because symbol-lookup debug is controlled by an 'unsigned int' rather
than a 'bool' control variable, we use the numeric value to offer
different levels of verbosity for symbol-lookup debug.
The *_SCOPED_DEBUG_ENTER_EXIT mechanism currently relies on capturing
a reference to the bool control variable, and evaluating the variable
both on entry, and at exit, this is done in the scoped_debug_start_end
class (see gdbsupport/common-debug.h).
This commit templates scoped_debug_start_end so that the class can
accept either a 'bool &' or an invokable object, e.g. a lambda
function, or a function pointer.
The existing scoped_debug_start_end and scoped_debug_enter_exit macros
in common-debug.h are updated to support scoped_debug_enter_exit being
templated, however, nothing outside of common-debug.h needs to change.
I've then added SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT in symtab.h, and
added a couple of token uses in symtab.c. I didn't want to add too
much in this first commit, this is really about updating
common-debug.h to support this new functionality.
Within symtab.h I created a couple of global functions that can be
used to query the status of the symbol_lookup_debug control variable,
these functions are then used within the two existing macros:
symbol_lookup_debug_printf
symbol_lookup_debug_printf_v
and also in the new SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT macro.
Convert the implementation of 'set debug symbol-lookup' to the new
debug printing scheme.
In a few places I've updated the debug output to remove places where
the printed debug message included the function name, the new debug
scheme already adds that, but I haven't done all the possible updates.
This commit provides a test for this commit:
commit 55fc1623f9
Date: Thu Nov 3 13:49:17 2022 -0600
Add name canonicalization for C
Which resolves PR gdb/29105. My reason for writing this test was a
desire to better understand the above commit, my process was to study
the commit until I thought I understood it, then write a test to
expose the issue. As the original commit didn't have a test, I
thought it wouldn't hurt to commit this upstream.
The problem tested for here is already described in the above commit,
but I'll give a brief description here. This description describes
GDB prior to the above commit:
- Builtin types are added to GDB using their canonical name,
e.g. "short", not "signed short",
- When the user does something like 'p sizeof(short)', then this is
handled in c-exp.y, and results in a call to lookup_signed_type
for the name "int". The "int" here is actually being looked up as
the type for the result of the 'sizeof' expression,
- In lookup_signed_type GDB first adds a 'signed' and looks for that
type, so in this case 'signed int', and, if that lookup fails, GDB
then looks up 'int',
- The problem is that 'signed int' is not the canonical name for a
signed int, so no builtin type with that name will be found, GDB
will then go to each object file in turn looking for a matching
type,
- When checking each object file, GDB will first check the partial
symtab to see if the full symtab should be expanded or not.
Remember, at this point GDB is looking for 'signed int', there
will be no partial symbols with that name, so GDB will not expand
anything,
- However, GDB checks each partial symbol using multiple languages,
not just the current language (C in this case), so, when GDB
checks using the C++ language, the symbol name is first
canonicalized (the code that does this can be found
lookup_name_info::language_lookup_name). As the canonical form of
'signed int' is just 'int', GDB then looks for any symbols with
the name 'int', most partial symtabs will contain such a symbol,
so GDB ends up expanding pretty much every symtab.
The above commit fixes this by avoiding the use of non-canonical names
with C, now the initial builtin type lookup will succeed, and GDB
never even considers whether to expand any additional symtabs.
The test case creates a library that includes char, short, int, and
long types, and a test program that links against the library.
In the test script we start the inferior, but don't allow it to
progress far enough that the debug information for the library has
been fully expanded yet.
Then we evaluate some 'sizeof(TYPE)' expressions.
In the buggy version of GDB this would cause the debug information
for the library to be fully expanded, while in the fixed version of
GDB this will not be the case.
We use 'info sources' to determine if the debug information has been
fully expanded or not.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105
The following commit broke the readnow detection in the testsuite:
commit dfaa040b44
Date: Mon Mar 29 18:31:31 2021 -0600
Remove some "OBJF_READNOW" code from dwarf2_debug_names_index
The testsuite checks if GDB was started with the -readnow flag by
using the 'maintenance print objfiles' command, and looking for the
string 'faked for "readnow"' in the output. This is implemented in
two helper procs `readnow` (gdb.exp) and `mi_readnow` (mi-support.exp).
The following tests all currently depend on this detection:
gdb.base/maint.exp
gdb.cp/nsalias.exp
gdb.dwarf2/debug-aranges-duplicate-offset-warning.exp
gdb.dwarf2/dw2-stack-boundary.exp
gdb.dwarf2/dw2-zero-range.exp
gdb.dwarf2/gdb-index-nodebug.exp
gdb.mi/mi-info-sources.exp
gdb.python/py-symbol.exp
gdb.rust/traits.exp
The following test also includes detection of 'readnow', but does the
detection itself by checking $::GDBFLAGS for the readnow flag:
gdb.opt/break-on-_exit.exp
The above commit removed from GDB the code that produced the 'faked
for "readnow"' string, as a consequence the testsuite can no longer
correctly spot when readnow is in use, and many of the above tests
will fail (at least partially).
When looking at the above tests, I noticed that gdb.rust/traits.exp
does call `readnow`, but doesn't actually use the result, so I've
removed the readnow call, this simplifies the next part of this patch
as gdb.rust/traits.exp was the only place an extra regexp was passed
to the readnow call.
Next I have rewritten `readnow` to check the $GDBFLAGS for the
-readnow flag, and removed the `maintenance print objfiles` check. At
least for all the tests above, when using the readnow board, this is
good enough to get everything passing again.
For the `mi_readnow` proc, I changed this to just call `readnow` from
gdb.exp, I left the mi_readnow name in place - in the future it might
be the case that we want to do some different checks here.
Finally, I updated gdb.opt/break-on-_exit.exp to call the `readnow`
proc.
With these changes, all of the tests listed above now pass correctly
when using the readnow board.
The current AS accepts invalid operands due to miss of operands length check.
For example, "e6" is an invalid operand in (vsetvli a0, a1, e6, mf8, tu, ma),
but it's still accepted by assembler. In detail, the condition check "strncmp
(array[i], *s, len) == 0" in arg_lookup function passes with "strncmp ("e64",
"e6", 2)" in the case above. So the generated encoding is same as that of
(vsetvli a0, a1, e64, mf8, tu, ma).
This patch fixes issue above by prompting an error in such case and also adds
a new testcase.
gas/ChangeLog:
* config/tc-riscv.c (arg_lookup): Add string length check for operands.
* testsuite/gas/riscv/vector-insns-fail-vsew.d: New testcase for an illegal vsew.
* testsuite/gas/riscv/vector-insns-fail-vsew.l: Likewise.
* testsuite/gas/riscv/vector-insns-fail-vsew.s: Likewise.
As Alan points out, ASAN takes issue with these constructs, for
current_templates being NULL. Wrap them in sizeof(), so the expressions
aren't actually evaluated.
* dwarf.c (struct Frame_Chunk): Make col_offset an int64_t.
Adjust all places allocating col_offset and col_type to use
the size of the array element rather than the size of a type.
(frame_display_row): Adjust printing of col_offset.
(display_debug_frames): Factor out multiplication by
code_factor and data_factor. Avoid signed overflow. Use
64-bit variables.
abfd->filename will be freed if bfd_close gets far enough to delete
the bfd. It's possible to have an error from fclose at this point.
* objcopy.c (copy_archive): Dup filename before closing bfd for
potential use in bfd_nonfatal_message.
As Hannes pointed out, the Windows target-async patches broke C-c
handling there. Looking into this, I found a few oddities, fixed
here.
First, windows_nat_target::interrupt calls GenerateConsoleCtrlEvent.
I think this event can be ignored by the inferior, so it's not a great
way to interrupt. Instead, using DebugBreakProcess (or a more
complicated thing for Wow64) seems better.
Second, windows_nat_target did not implement the pass_ctrlc method.
Implementing this lets us remove the special code to call
SetConsoleCtrlHandler and instead integrate into gdb's approach to C-c
handling. I believe that this should also fix the race that's
described in the comment that's being removed.
Initially, I thought a simpler version of this patch would work.
However, I think what happens is that some other library (I'm not sure
what) calls SetConsoleCtrlHandler while gdb is running, and this
intercepts and handles C-c -- so that the gdb SIGINT handler is not
called. C-break continues to work, presumably because whatever
handler is installed ignores it.
This patch works around this issue by ensuring that the gdb handler
always comes first.
This refactors the code to check for terminal sharing.
is_gdb_terminal is exported, and sharing_input_terminal_1 is renamed,
slightly refactored, and moved to posix-hdep.c. A new
Windows-specific implementation of this function is added to
mingw-hdep.c.
MSDN has a warning about GetConsoleProcessList
This API is not recommended and does not have a virtual terminal
equivalent. [...] Applications remoting via cross-platform
utilities and transports like SSH may not work as expected if
using this API.
However, we believe this isn't likely to be an issue for gdb.
sigint_ours (and sigquit_ours) can be used without being set. Avoid
this problem by changing them to gdb::optional and checking that they
are in fact set before using the value.
On s390x-linux, I run into:
...
(gdb) continue^M
Continuing.^M
breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: \
Assertion `!target_stopped_by_watchpoint ()' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
FAIL: gdb.threads/watchpoint-fork.exp: parent: singlethreaded: \
breakpoint after the first fork (GDB internal error)
...
What happens is the follow:
- a watchpoint event triggers
- the event is processed, s390_linux_nat_target::stopped_by_watchpoint is called and
it returns true, as expected
- the watchpoint event is reported by gdb, and gdb stops
- we issue a continue command
- a fork event triggers
- the event is processed, and during processing that event
s390_linux_nat_target::stopped_by_watchpoint is called again, and returns
true
- the assertion fails, because the function is expected to return false
The function s390_linux_nat_target::stopped_by_watchpoint returns true the
second time, because it looks at the exact same data that was looked at when
it was called the first time, and that data hasn't changed.
There's code in the same function that intends to prevent that from happening:
...
/* Do not report this watchpoint again. */
memset (&per_lowcore, 0, sizeof (per_lowcore));
if (ptrace (PTRACE_POKEUSR_AREA, s390_inferior_tid (), &parea, 0) < 0)
perror_with_name (_("Couldn't clear watchpoint status"));
...
and that probably used to work for older kernels, but no longer does since
linux kernel commit 5e9a26928f55 ("[S390] ptrace cleanup").
Fix this by copying this:
...
siginfo_t siginfo;
if (!linux_nat_get_siginfo (inferior_ptid, &siginfo))
return false;
if (siginfo.si_signo != SIGTRAP
|| (siginfo.si_code & 0xffff) != TRAP_HWBKPT)
return false;
...
from aarch64_linux_nat_target::stopped_data_address and remove the
obsolete watchpoint status clearing code.
Tested on s390x-linux.
Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
Since MPX support has been removed from x86-64 psABI, remove BND from
64-bit IBT PLT by using 32-bit IBT PLT.
PR gold/29851
* x86_64.cc (Output_data_plt_x86_64_ibt<32>::first_plt_entry):
Renamed to ...
(Output_data_plt_x86_64_ibt<size>::first_plt_entry): This.
(Output_data_plt_x86_64_ibt<64>::first_plt_entry): Removed.
(Output_data_plt_x86_64_ibt<size>::do_fill_first_plt_entry):
Drop the size == 32 check.
(Output_data_plt_x86_64_ibt<32>::plt_entry): Renamed to ...
(Output_data_plt_x86_64_ibt<size>::plt_entry): This.
(Output_data_plt_x86_64_ibt<64>::plt_entry): Removed.
(Output_data_plt_x86_64_ibt<32>::aplt_entry): Renamed to ...
(Output_data_plt_x86_64_ibt<size>::aplt_entry): This.
(Output_data_plt_x86_64_ibt<64>::aplt_entry): Removed.
(Output_data_plt_x86_64_ibt<size>::do_fill_plt_entry): Drop the
size == 32 check.
(Output_data_plt_x86_64_ibt<size>::fill_aplt_entry): Likewise.
A couple of calls to parse_probe_linespec had an unnecessary cast. I
suspect this cast was never needed, but once commands were changed to
take a 'const' argument, they became completely obsolete. Tested by
rebuilding.
After this commit:
commit 33c1395cf5
Date: Fri Nov 11 15:26:46 2022 +0000
gdb/testsuite: fix gdb.trace/unavailable-dwarf-piece.exp with Clang
The gdb.trace/unavailable-dwarf-piece.exp test script was creating a
temporary file in the build/gdb/testsuite/ directory, instead of in
the expected place in the outputs directory.
Fix this by adding a call to standard_output_file.
On s390x-linux, I run into:
...
(gdb) disassemble test^M
Dump of assembler code for function test:^M
0x0000000001000638 <+0>: stg %r11,88(%r15)^M
0x000000000100063e <+6>: lgr %r11,%r15^M
0x0000000001000642 <+10>: nop 0^M
=> 0x0000000001000646 <+14>: nop 0^M
0x000000000100064a <+18>: nop 0^M
0x000000000100064e <+22>: lhi %r1,0^M
0x0000000001000652 <+26>: lgfr %r1,%r1^M
0x0000000001000656 <+30>: lgr %r2,%r1^M
0x000000000100065a <+34>: lg %r11,88(%r11)^M
0x0000000001000660 <+40>: br %r14^M
End of assembler dump.^M
(gdb) FAIL: gdb.python/py-disasm.exp: global_disassembler=: disassemble test
...
The problem is that the test-case expects "nop" but on s390x we have instead
"nop\t0".
Fix this by allowing the insn.
Tested on s390x-linux and x86_64-linux.
The PR gas/16908 workaround aimed at uniformly reporting line numbers
to reference macro invocation sites. As mentioned in a comment this may
be desirable for small macros, but often isn't for larger ones. As a
first step improve diagnostics to report both locations, while aiming at
leaving generated debug info unaltered.
Note that macro invocation context is lost for any diagnostics issued
only after all input was processed (or more generally for any use of
as_*_where(), as the functions can't know whether the passed in location
is related to [part of] the present stack of locations). To maintain the
intended workaround behavior for PR gas/16908, a new as_where() is
introduced to "look through" macro invocations, while the existing
as_where() is renamed (and used in only very few places for now). Down
the road as_where() will likely want to return a list of (file,line)
pairs.
Macros with just a single use site are a little pointless to have, and
even in further cases .irp is more suitable for the purpose. Expand such
inline, avoiding the need to touch the testcases when diagnostics are
changed for code resulting from macro expansion.
While there also make what was "iter_mla" in sp-usage-thumb2-relax cover
smlatt as well, rather than testing smlabt twice.
is_nocall_function anticipates only being called for a function or a
method. However, PR gdb/29871 points out a situation where an unusual
expression -- but one that parses to a valid, if extremely weird,
function call -- breaks this assumption.
This patch changes is_nocall_function to remove this assert and
instead simply return 'false' in this case.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29871
In 2014, the function `gdbpy_should_stop' has been replaced with
`gdbpy_breakpoint_cond_says_stop'
This replaces `gdbpy_should_stop' with `gdbpy_breakpoint_cond_says_stop' in the
comments.
Since `gdbpy_should_stop' has been renamed as noted in `gdb/ChangeLog-2014':
* python/py-breakpoint.c (gdbpy_breakpoint_cond_says_stop): Renamed
from gdbpy_should_stop. Change result type to enum scr_bp_stop.
Change-Id: I0ef3491ce5e057c5e75ef8b569803b30a5838575
Approved-By: Simon Marchi <simon.marchi@efficios.com>
static variables like mips_hi16_list are nasty for applications using
bfd. It is possible when opening and closing bfds with mis-matched
hi/lo relocs to leave a stale section pointer on the list. That can
cause a segfault if multiple bfds are being processed.
Tidying the list when closing is sufficient to stop this happening
(and fixes small memory leaks). This patch goes further and moves
mips_hi16_list to where it belongs in the bfd tdata.
* elf32-mips.c (bfd_elf32_close_and_cleanup(: Define.
* elf64-mips.c (bfd_elf64_close_and_cleanup): Define.
* elfn32-mips.c (bfd_elf32_close_and_cleanup(: Define.
* elfxx-mips.c (struct mips_hi16): Move earlier.
(mips_hi16_list): Move to..
(struct mips_elf_obj_tdata): ..here.
(_bfd_mips_elf_close_and_cleanup): New function.
(_bfd_mips_elf_hi16_reloc, _bfd_mips_elf_lo16_reloc),
(_bfd_elf_mips_get_relocated_section_contents): Adjust uses of
mips_hi16_list.
* elfxx-mips.h (_bfd_mips_elf_close_and_cleanup): Declare.
This patch is essentially a revert of
commit-id: 8818c80cbd
(libctf: Add ZSTD_LIBS to LIBS so that ac_cv_libctf_bfd_elf can be true)
As the specific configure check now uses libtool, this explicit mention of the
dependency $ZSTD_LIBS is not needed anymore.
ChangeLog:
* libctf/Makefile.in: Regenerated.
* libctf/aclocal.m4: Likewise.
* libctf/config.h.in: Likewise.
* libctf/configure: Likewise.
* libctf/configure.ac: Remove ZSTD_LIBS from LIBS. Cleanup
unused AC_ZSTD.
ACLOCAL_AMFLAGS is being set already. So using AC_CONFIG_MACRO_DIR is
unnecessary.
ChangeLog:
* libctf/configure: Regenerated.
* libctf/configure.ac: remove AC_CONFIG_MACRO_DIR usage.
This dependency is managed via libtool. So explicit addition to LDFLAGS
and LIBS is not necessary anymore.
ChangeLog:
* libctf/configure: Regenerated.
* libctf/configure.ac: remove zlib from LDFLAGS and LIBS.
On s390x-linux, I run into:
...
(gdb) print {unsigned char}{65}^M
$749 = 0 '\000'^M
(gdb) FAIL: gdb.base/printcmds.exp: print {unsigned char}{65}
...
In contrast, on x86_64-linux, we have:
...
(gdb) print {unsigned char}{65}^M
$749 = 65 'A'^M
(gdb) PASS: gdb.base/printcmds.exp: print {unsigned char}{65}
...
The first problem here is that the test is supposed to be a regression test
for PR20630, which can be reproduced (for an unfixed gdb) like this:
...
(gdb) p {unsigned char[]}{0x17}
gdbtypes.c:4641: internal-error: copy_type: \
Assertion `TYPE_OBJFILE_OWNED (type)' failed.
...
but it's not due to insufficient quoting (note the dropped '[]').
That's easy to fix, but after that we have on s390 (big endian):
...
(gdb) print {unsigned char[]}{65}^M
$749 = ""^M
...
and on x86_64 (little endian):
...
(gdb) print {unsigned char[]}{65}^M
$749 = "A"^M
...
Fix this by using 0xffffffff, such that in both cases we have:
...
(gdb) print {unsigned char[]}{0xffffffff}^M
$749 = "\377\377\377\377"^M
...
Tested on x86_64-linux and s390x-linux.
My earlier patch to fix PR rust/29859 introduced a new operator
precedence bug in the Rust parser. Assignment operators are
right-associative in Rust. And, while this doesn't often matter, as
Rust assignments always have the value (), still as a matter of
principle we should get this correct.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29859
On s390x-linux (big endian), I run into:
...
(gdb) x /xh main^M
0x1000638 <main>: 0x0000^M
(gdb) FAIL: gdb.base/write_mem.exp: x /xh main
...
In contrast, on x86_64-linux (little endian), we have the expected:
...
(gdb) x /xh main^M
0x4004a7 <main>: 0x4242^M
(gdb) PASS: gdb.base/write_mem.exp: x /xh main
...
The problem is that the test-case hard-codes expectations about endiannes by
writing an int-sized value (4 bytes in this case) and then printing only a
halfword by using "/h" (so, two bytes).
If we print 4 bytes, we have for s390x:
...
0x1000638 <main>: 0x00004242^M
...
and for x86_64:
...
0x4004a7 <main>: 0x00004242^M
...
Fix this by removing the "/h".
Tested on x86_64-linux and s390x-linux.
In principle, `execute_command()` does following:
struct cmd_list_element *c;
c = lookup_cmd ( ... );
...
/* If this command has been pre-hooked, run the hook first. */
execute_cmd_pre_hook (c);
...
/* ...execute the command `c` ...*/
...
execute_cmd_post_hook (c);
This may lead into use-after-free error. Imagine the command
being executed is a user-defined Python command that redefines
itself. In that case, struct `cmd_list_element` pointed to by
`c` is deallocated during its execution so it is no longer valid
when post hook is executed.
To fix this case, this commit looks up the command once again
after it is executed to get pointer to (possibly newly allocated)
`cmd_list_element`.
PR gas/29524
Having templates with a suffix explicitly present has always been
quirky. After prior adjustment all that's left to also eliminate the
anomaly from move-with-sign-extend is to consolidate the insn templates
and to make may_need_pass2() cope (plus extend testsuite coverage).
The need for them on the operand-less string insns has gone away with
the removal of maybe_adjust_templates() and associated logic. Since
i386_index_check() needs adjustment then anyway, take the opportunity
and also simplify it, possible again as a result of said removal (plus
the opcode template adjustments done here).
Having it in match_template() is unhelpful. Neither does looking for the
next template to possibly match make any sense in that case, nor is the
resulting diagnostic making clear what the problem is.
While moving the check, also generalize it to include all SIMD and VEX-
encoded insns. This way an existing conditional can be re-used in
md_assemble(). Note though that this still leaves a lof of insns which
are also wrong to use with these relocations.
Further fold the remaining check (BFD_RELOC_386_GOT32) with the XRELEASE
related one a few lines down. This again allows re-using an existing
conditional.
In commit 1212781b35 ("ix86: allow HLE store of accumulator to
absolute address") I was wrong to exclude 64-bit code. Dropping the
check also leads to better diagnostics in 64-bit code ("MOV", after
all, isn't invalid with "XRELEASE").
While there also limit the amount of further checks done: The operand
type checks that were there were effectively redundant with other ones
anyway, plus it's quite fine to also have "xrelease mov <disp>, %eax"
look for the next MOV template (in fact again also improving
diagnostics).
Have its use, except where actually legitimate, result in the same "only
supported in 64-bit mode" diagnostic as emitted for other 64-bit only
insns. Also suppress deriving of the suffix in Intel mode except in the
legitimate cases. This in exchange allows dropping the respective code
from match_template().
To maintain reasonable diagnostics (in particular to avoid "`mov' is
only supported in 64-bit mode" on the SIMD forms of MOVQ) we need to
defer parse_insn()'s emitting of errors unrelated to prefix parsing.
Utilize i.error just like match_template() does.
Oddly enough despite gcc's preference towards FILDQ and FIST{,T}Q we
had no testcase whatsoever for these. Therefore such tests are being
added. Note that the removed line in the x86-64-lfence-load testcase
was redundant with the exact same one a few lines up.
Having templates with a suffix explicitly present has always been
quirky. Introduce a 2nd matching pass in case the 1st one couldn't find
a suitable template _and_ didn't itself already need to trim off a
suffix to find a match at all. This requires error reporting adjustments
(albeit luckily fewer than I was afraid might be necessary), as errors
previously reported during matching now need deferring until after the
2nd pass (because, obviously, we must not emit any error if the 2nd pass
succeeds). While also related to PR gas/29524, it was requested that
move-with-sign-extend be left as broken as it always was.
PR gas/29525
Note that with the dropped CMPSD and MOVSD Intel Syntax string insn
templates taking operands, mixed IsString/non-IsString template groups
(with memory operands) cannot occur anymore. With that
maybe_adjust_templates() becomes unnecessary (and is hence being
removed).
PR gas/29526
Note further that while the additions to the intel16 testcase aren't
really proper Intel syntax, we've been permitting all of those except
for the MOVD variant. The test therefore is to avoid re-introducing such
an inconsistency.
The function doesn't alter its input buffer: Reflect this in its
prototype. To avoid using any kind of cast, simply calculate the update
of "line" from the function's input and output.
This reverts the disassembler parts of 859aa2c86d ("x86: Allow 16-bit
register source for LAR and LSL"), adjusting testcases as necessary.
That change was itself a partial revert of c9f5b96bda ("x86: correct
handling of LAR and LSL"), without actually saying so. While the earlier
commit was properly agreed upon, the partial revert was not, and hence
should not have been committed. This is even more so that the revert
part of that change wasn't even necessary to address PR gas/29844.
Plus segvs if the C-library doesn't handle printf %s of NULL.
PR 29872
* dwarf.c (null_name): New function.
(process_debug_info): Use it here..
(display_debug_lines_raw): ..and here..
(display_debug_lines_decoded): ..and here. xcalloc directory_table.
Simplify xcalloc of file_table.
While not "index" this time, old enough glibc also has an (unguarded)
declaration of fileno() in stdio.h, which triggers a "shadows a global
declaration" warning with our choice of warning level and with at least
some gcc versions.
Speed up gas startup by avoiding runtime allocation of the instances of
type "templates". At the same time cut the memory requirement to just
very little over half (not even accounting for any overhead
notes_alloc() may incur) by reusing the "end" slot of a preceding entry
for the "start" slot of the subsequent one.
Now that the table is local to gas, ARRAY_SIZE() can be used to
determine the end of the table. Re-arrange the processing loop in
md_begin() accordingly, at the same time folding the two calls to
notes_alloc() into just one.
As requested by H.J., just for the sake of people potentially building
in gas/ alone, add a check that the generated files in opcodes/ are
actually up-to-date. Personally I think this should at best be a
warning, but I can see how this may not be easily noticable among other
make output (depending in particular on the verbosity level).
