| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
String-like settings (var_string, var_filename, var_optional_filename,
var_string_noescape) currently take a pointer to a `char *` storage
variable (typically global) that holds the setting's value. I'd like to
"mordernize" this by changing them to use an std::string for storage.
An obvious reason is that string operations on std::string are often
easier to write than with C strings. And they avoid having to do any
manual memory management.
Another interesting reason is that, with `char *`, nullptr and an empty
string often both have the same meaning of "no value". String settings
are initially nullptr (unless initialized otherwise). But when doing
"set foo" (where `foo` is a string setting), the setting now points to
an empty string. For example, solib_search_path is nullptr at startup,
but points to an empty string after doing "set solib-search-path". This
leads to some code that needs to check for both to check for "no value".
Or some code that converts back and forth between NULL and "" when
getting or setting the value. I find this very error-prone, because it
is very easy to forget one or the other. With std::string, we at least
know that the variable is not "NULL". There is only one way of
representing an empty string setting, that is with an empty string.
I was wondering whether the distinction between NULL and "" would be
important for some setting, but it doesn't seem so. If that ever
happens, it would be more C++-y and self-descriptive to use
optional<string> anyway.
Actually, there's one spot where this distinction mattered, it's in
init_history, for the test gdb.base/gdbinit-history.exp. init_history
sets the history filename to the default ".gdb_history" if it sees that
the setting was never set - if history_filename is nullptr. If
history_filename is an empty string, it means the setting was explicitly
cleared, so it leaves it as-is. With the change to std::string, this
distinction doesn't exist anymore. This can be fixed by moving the code
that chooses a good default value for history_filename to
_initialize_top. This is ran before -ex commands are processed, so an
-ex command can then clear that value if needed (what
gdb.base/gdbinit-history.exp tests).
Another small improvement, in my opinion is that we can now easily
give string parameters initial values, by simply initializing the global
variables, instead of xstrdup-ing it in the _initialize function.
In Python and Guile, when registering a string-like parameter, we
allocate (with new) an std::string that is owned by the param_smob (in
Guile) and the parmpy_object (in Python) objects.
This patch started by changing all relevant add_setshow_* commands to
take an `std::string *` instead of a `char **` and fixing everything
that failed to build. That includes of course all string setting
variable and their uses.
string_option_def now uses an std::string also, because there's a
connection between options and settings (see
add_setshow_cmds_for_options).
The add_path function in source.c is really complex and twisted, I'd
rather not try to change it to work on an std::string right now.
Instead, I added an overload that copies the std:string to a `char *`
and back. This means more copying, but this is not used in a hot path
at all, so I think it is acceptable.
Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93
Co-authored-by: Lancelot SIX <lsix@lancelotsix.com>
|
|
cmd_list_element can contain a pointer to data that can be set and / or
shown. This is achieved with the void* VAR member which points to the
data that can be accessed, while the VAR_TYPE member (of type enum
var_types) indicates how to interpret the data pointed to.
With this pattern, the user of the cmd_list_element needs to know what
is the storage type associated with a given VAR_TYPES in order to do
the proper casting. No automatic safeguard is available to prevent
miss-use of the pointer. Client code typically looks something like:
switch (c->var_type)
{
case var_zuinteger:
unsigned int v = *(unsigned int*) c->var;
...
break;
case var_boolean:
bool v = *(bool *) c->var;
...
break;
...
}
This patch proposes to add an abstraction around the var_types and void*
pointer pair. The abstraction is meant to prevent the user from having
to handle the cast and verify that the data is read or written as a type
that is coherent with the setting's var_type. This is achieved by
introducing the struct setting which exposes a set of templated get /
set member functions. The template parameter is the type of the
variable that holds the referred variable.
Using those accessors allows runtime checks to be inserted in order to
ensure that the data pointed to has the expected type. For example,
instantiating the member functions with bool will yield something
similar to:
const bool &get<bool> () const
{
gdb_assert (m_var_type == var_boolean);
gdb_assert (m_var != nullptr);
return *static_cast<bool *> (m_var);
}
void set<bool> (const bool &var)
{
gdb_assert (m_var_type == var_boolean);
gdb_assert (m_var != nullptr);
*static_cast<bool *> (m_var) = var;
}
Using the new abstraction, our initial example becomes:
switch (c->var_type)
{
case var_zuinteger:
unsigned int v = c->var->get<unsigned int> ();
...
break;
case var_boolean:
bool v = c->var->get<bool> ();
...
break;
...
}
While the call site is still similar, the introduction of runtime checks
help ensure correct usage of the data.
In order to avoid turning the bulk of add_setshow_cmd_full into a
templated function, and following a suggestion from Pedro Alves, a
setting can be constructed from a pre validated type erased reference to
a variable. This is what setting::erased_args is used for.
Introducing an opaque abstraction to describe a setting will also make
it possible to use callbacks to retrieve or set the value of the setting
on the fly instead of pointing to a static chunk of memory. This will
be done added in a later commit.
Given that a cmd_list_element may or may not reference a setting, the
VAR and VAR_TYPES members of the struct are replaced with a
gdb::optional<setting> named VAR.
Few internal function signatures have been modified to take into account
this new abstraction:
-The functions value_from_setting, str_value_from_setting and
get_setshow_command_value_string used to have a 'cmd_list_element *'
parameter but only used it for the VAR and VAR_TYPE member. They now
take a 'const setting &' parameter instead.
- Similarly, the 'void *' and a 'enum var_types' parameters of
pascm_param_value and gdbpy_parameter_value have been replaced with a
'const setting &' parameter.
No user visible change is expected after this patch.
Tested on GNU/Linux x86_64, with no regression noticed.
Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca>
Change-Id: Ie1d08c3ceb8b30b3d7bf1efe036eb8acffcd2f34
|
|
We map target signals to host signals so we can propagate signals
between the host & simulated worlds. That means we need to know
the symbolic names & values of all signals that might be sent.
The tools that generate that list use signal.h and include all
symbols that start with "SIG" so as to automatically include any
new symbols that the C library might add. Unfortunately, this
also picks up "SIGSTKSZ" which is not actually a signal itself,
but a signal related setting -- it's the size of the stack when
a signal is handled.
By itself this doesn't super matter as we will never see a signal
with that same value (since the range of valid signals tend to be
way less than 1024, and the size of the default signal stack will
never be that small). But with recent glibc changes that make this
into a dynamic value instead of a compile-time constant, some users
see build failures when building the sim.
As suggested by Adam Sampson, update our scripts to ignore this
symbol to simplify everything and avoid the build failure.
Bug: https://sourceware.org/PR28302
|
|
Not all systems have easy access to hard links or symlinks, so add
fallback logic to the run->psim build code to handle those.
Bug: https://sourceware.org/PR18864
|
|
I found an inaccurate comment in riscv_scan_prologue. This commit fixes
it.
|
|
While working on other problems, I encountered situations where GDB
fails to properly unwind the stack because some functions use the C.MV
instruction in the prologue. The prologue scanner stops when it hits
this instruction assuming its job is done at this point. Unfortunately
the prologue is not necessarily finished yet, preventing GDB to properly
unwind.
This commit adds support for handling such instruction in
riscv_scan_prologue.
Note that C.MV is part of the compressed instruction set. The MV
counterpart from the base ISA is a pseudo instruction that expands to
'ADDI RD,RS1,0' which is already supported.
Tested on riscv64-linux-gnu.
All feedback are welcome.
|
|
|
|
Remove macro COMPUNIT_CALL_SITE_HTAB, and provide access to the htab using
member functions:
- compunit_symtab::find_call_site
- compunit_symtab::set_call_site_htab
Tested on x86_64-linux.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
|
|
Fix these rather obvious warnings reported by flake8:
./lib/gdb/FrameIterator.py:16:1: F401 'gdb' imported but unused
./lib/gdb/FrameIterator.py:17:1: F401 'itertools' imported but unused
./lib/gdb/command/prompt.py:55:26: E712 comparison to False should be 'if cond is False:' or 'if not cond:'
./lib/gdb/command/explore.py:526:9: F841 local variable 'has_explorable_fields' is assigned to but never used
./lib/gdb/command/explore.py:697:56: E712 comparison to False should be 'if cond is False:' or 'if not cond:'
./lib/gdb/command/explore.py:736:62: E712 comparison to False should be 'if cond is False:' or 'if not cond:'
./lib/gdb/command/explore.py:767:61: E712 comparison to False should be 'if cond is False:' or 'if not cond:'
./lib/gdb/command/frame_filters.py:21:1: F401 'copy' imported but unused
./lib/gdb/command/frame_filters.py:22:1: F401 'gdb.FrameIterator.FrameIterator' imported but unused
./lib/gdb/command/frame_filters.py:23:1: F401 'gdb.FrameDecorator.FrameDecorator' imported but unused
./lib/gdb/command/frame_filters.py:25:1: F401 'itertools' imported but unused
./lib/gdb/command/frame_filters.py:179:17: E712 comparison to True should be 'if cond is True:' or 'if cond:'
Change-Id: I4f49c0cb430359ee872222600c61d9c5283b09ab
|
|
|
|
When building master GDB, I ran into the following:
binutils-gdb/gdb/bt-utils.c: In function 'int libbacktrace_print(void*, uintptr_t, const char*, int, const char*)':
binutils-gdb/gdb/bt-utils.c:93:44: error: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'uintptr_t {aka unsigned int}' [-Werror=format=]
snprintf (buf, sizeof (buf), "0x%lx ", pc);
Fix this by using %PRIxPTR as opposed to %lx.
|
|
|
|
In read_call_site_scope we have:
...
call_site_local.pc = pc;
slot = htab_find_slot (cu->call_site_htab, &call_site_local, INSERT);
...
The call passes a call_site pointer as element. OTOH, the hashtab is created
using hash_f == core_addr_hash and eq_f == core_addr_eq, so the element
will be accessed through a CORE_ADDR pointer.
This is not wrong (at least in C), given that pc is the first field in
call_site.
Nevertheless, as in call_site_for_pc, make the htab_find_slot call match the
used hash_f and eq_f by using &pc instead:
...
slot = htab_find_slot (cu->call_site_htab, &pc, INSERT);
...
Tested on x86_64-linux.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
|
|
2021-09-27 Andrea Corallo <andrea.corallo@arm.com>
* elf-bfd.h (NUM_KNOWN_OBJ_ATTRIBUTES): Update value to cover
'Tag_BTI_use' and 'Tag_PACRET_use'.
|
|
Change how rnglists and loclists procs to align them with how procs for
aranges (and other things in the DWARF assembler) work. Instead of
using "args" (variable number of parameters in TCL) and command-line
style option arguments, use one leading "option" parameters, used as a
kind of key/value dictionary of options parsed using `parse_options`.
Change-Id: I63e60d17ae16a020ce4d6de44baf3d152ea42a1a
|
|
When I wrote support for rnglists and loclists in the testsuite's DWARF
assembler, I made it with nested procs, for example proc "table" inside
proc "rnglists". The intention was that this proc "table" could only be
used by the user while inside proc "rnglists"'s body. I had chosen very
simple names, thinking there was no chance of name clashes. I recently
learned that this is not how TCL works. This ends up defining a proc
"table" in the current namespace ("Dwarf" in this case).
Things still work if you generate rnglists and loclists in the same
file, as each redefines its own procedures when executing. But if a
user of the assembler happened to define a convenience "table" or
"start_end" procedure, for example, it would get overriden.
I'd like to change how this works to reduce the chances of a name clash.
- Move the procs out of each other, so they are not defined in a nested
fashion.
- Prefix them with "_rnglists_" or "_loclists_".
- While calling $body in the various procs, temporarily make the procs
available under their "short" name. For example, while in rngllists'
body, make _rnglists_table available as just "table". This allows
existing code to keep working and keeps it not too verbose.
- Modify with_override to allow the overriden proc to not exist. In
that case, the temporary proc is deleted on exit.
Note the non-conforming indentation when calling with_override in
_loclists_list. This is on purpose: as we implement more loclists (and
rnglists) entry types, the indentation would otherwise get larger and
larger without much value for readability. So I think it's reasonable
here to put them on the same level.
Change-Id: I7bb48d26fcb0dba1ae4dada05c0c837212424328
|
|
Remove the `TYPE_FIELD_NAME` and `FIELD_NAME` macros, changing all the
call sites to use field::name directly.
Change-Id: I6900ae4e1ffab1396e24fb3298e94bf123826ca6
|
|
Add the `name` and `set_name` methods on `struct field`, in order to
remove `FIELD_NAME` and `TYPE_FIELD_NAME` macros. In this patch, the
macros are changed to use `field::name`, so all the call sites that are
used to set the field's name are changed to use `field::set_name`.
The next patch will remove the macros completely.
Note that because of the name clash between the existing field named
`name` and the new method, I renamed the field `m_name`. It is not
private per-se, because we can't make `struct field` a non-POD yet, but
it should be considered private anyway (not accessed outside `struct
field`).
Change-Id: If16ddbca4e0c39d0ff9da420bb5cdebe5b9b0896
|
|
|
|
PR gdb/28369 reports that gdb/ser-pipe.c has an 'execl' function call
with a hard-coded "/bin/sh" as its argument. We've had 'get_shell'
for a while now, which is conscious about the SHELL environment and a
better alternative to always calling "/bin/sh".
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28369
|
|
Add untested in case missing xml support is detected in test-cases
gdb.base/valgrind*.exp.
Tested on x86_64-linux.
|
|
Patch is adding Cortex-R52+ as 'cortex-r52plus' command line
flag for -mcpu option.
bfd/
* cpu-arm.c: New Cortex-R52+ CPU.
gas/
* NEWS: Update docs.
* config/tc-arm.c: New Cortex-R52+ CPU.
* doc/c-arm.texi: Update docs.
* testsuite/gas/arm/cpu-cortex-r52plus.d: New test.
|
|
This patch is adding support for Cortex-X2 CPU.
gas:
* NEWS: Update docs.
* config/tc-aarch64.c: Add Cortex-X2.
* doc/c-aarch64.texi: Update docs.
|
|
This patch is adding support for Cortex-A710 CPU.
gas/
* NEWS: Update docs.
* config/tc-aarch64.c: Add Cortex-A710.
* doc/c-aarch64.texi: Update docs.
|
|
This patch is adding support for Cortex-A510 CPU.
gas/
* NEWS: Update docs.
* config/tc-aarch64.c: Add Cortex-A510.
* doc/c-aarch64.texi: Update docs.
|
|
Patch is only sorting by 'Extension` column 'Architecture Extension'
table.
gas/
* doc/c-aarch64.texi: Update docs.
|
|
Patch is improving entries in "Architecture extensions" table in GAS
documentation.
gas/
* doc/c-aarch64.texi: Update docs.
|
|
Patch is adding new 'armv9-a` command line flag to -march for AArch64.
gas/
* config/tc-aarch64.c: Add 'armv9-a' command line flag.
* docs/c-aarch64.text: Update docs.
* NEWS: Update docs.
include/
* opcode/aarch64.h (AARCH64_FEATURE_V9): New define.
(AARCH64_ARCH_V9): New define.
|
|
As follow-up to this discussion:
https://sourceware.org/pipermail/gdb-patches/2020-August/171385.html
... make runto_main not pass no-message to runto. This means that if we
fail to run to main, for some reason, we'll emit a FAIL. This is the
behavior we want the majority of (if not all) the time.
Without this, we rely on tests logging a failure if runto_main fails,
otherwise. They do so in a very inconsisteny mannet, sometimes using
"fail", "unsupported" or "untested". The messages also vary widly.
This patch removes all these messages as well.
Also, remove a few "fail" where we call runto (and not runto_main). by
default (without an explicit no-message argument), runto prints a
failure already. In two places, gdb.multi/multi-re-run.exp and
gdb.python/py-pp-registration.exp, remove "message" passed to runto.
This removes a few PASSes that we don't care about (but FAILs will still
be printed if we fail to run to where we want to). This aligns their
behavior with the rest of the testsuite.
Change-Id: Ib763c98c5f4fb6898886b635210d7c34bd4b9023
|
|
This encourages the callers to use automatic file descriptor management.
Change-Id: I137a81df6f3607b457e28c35aafde8ed6f3a3344
|
|
Make gdb_open_cloexec return a scoped_fd, to encourage using automatic
management of the file descriptor closing. Except in the most trivial
cases, I changed the callers to just release the fd, which retains their
existing behavior. That will allow the transition to using scoped_fd
more to go gradually, one caller at a time.
Change-Id: Ife022b403f96e71d5ebb4f1056ef6251b30fe554
|
|
The following patches wants to change gdb_fopen_cloexec and
gdb_mkostemp_cloexec to return a scoped_fd. Doing this causes a cyclic
include between scoped_fd.h and filestuff.h, that both want to include
each other. scoped_fd.h includes filestuff.h because of the
scoped_fd::to_file method's return value. filestuff.h would then
include scoped_fd.h for gdb_fopen_cloexec's and gdb_mkostemp_cloexec's
return values.
To fix that, move gdb_file_up to its own file, gdb_file.h.
Change-Id: Ic82a48914b2aacee8f14af535b7469245f88b93d
|
|
My commit 261980de18b added alignment for the resource table symbol.
But it is wrong. The Linux remoteproc driver loads and interprets the
contents of the .resource_table ELF section, not of a table symbol.
Without this patch, if the linker happens to output padding for symbol
alignment, then the resource table contents as viewed by the kernel
loader would "shift" and look corrupted.
ld/ChangeLog:
* scripttempl/pru.sc (.resource_table): Align the output
section, not the first symbol.
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
|
|
The "make thread_suspend_state::stop_pc optional" patch caused a
regression on Windows when using shared libraries. I tracked this
down to an unguarded use of stop_pc() in the TARGET_WAITKIND_LOADED
case of handle_inferior_event. This patch fixes the bug by ensuring
that the stop PC is set at this point.
|
|
With running test-case gdb.debuginfod/fetch_src_and_symbols.exp with target
board unix/-bad, I get:
...
gcc: error: unrecognized command line option '-bad'^M
compiler exited with status 1
gdb compile failed, gcc: error: unrecognized command line option '-bad'
FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: compile
...
Replace the FAIL with the usual:
...
UNTESTED: gdb.debuginfod/fetch_src_and_symbols.exp: failed to compile
...
Tested on x86_64-linux.
|
|
When running test-case gdb.base/info-os.exp with target board unix/-bad, I run
into:
...
gdb compile failed, gcc: error: unrecognized command line option '-bad'
UNTESTED: gdb.base/info-os.exp: failed to prepare
FAIL: gdb.base/info-os.exp: cannot compile test program
...
Remove the redundant FAIL.
Tested on x86_64-linux.
|
|
When running test-case gdb.base/info-os.exp, I run into:
...
PASS: gdb.base/info-os.exp: get threads
PASS: gdb.base/info-os.exp: get threads
DUPLICATE: gdb.base/info-os.exp: get threads
...
Fix this not doing pass followed by exp_continue in gdb_test_multiple.
Tested on x86_64-linux.
|
|
When running test-case gdb.dwarf2/dw2-opt-structptr.exp with target board
unix/-bad, I get:
...
gdb compile failed, gcc: error: unrecognized command line option '-bad'
UNTESTED: gdb.dwarf2/dw2-opt-structptr.exp: dw2-opt-structptr.exp
UNTESTED: gdb.dwarf2/dw2-opt-structptr.exp: failed to compile
ERROR: (dw2-opt-structptr) No such file or directory
UNRESOLVED: gdb.dwarf2/dw2-opt-structptr.exp: console: set print object on
...
Merge the two UNTESTEDs.
Fix the UNRESOLVED by checking result of compilation.
Tested on x86_64-linux.
|
|
When running test-case gdb.base/structs.exp with target board unix/-bad, I
get:
...
gdb compile failed, gcc: error: unrecognized command line option '-bad'
UNTESTED: gdb.base/structs.exp: failed to prepare
ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/structs.exp.
ERROR: can't read "use_gdb_stub": no such variable
...
Fix this by checking the compilation result.
Fix the resulting DUPLICATEs using with_test_prefix.
Tested on x86_64-linux.
|
|
When running test-case gdb.base/cvexpr.exp with target board unix/-bad, I get:
...
gdb compile failed, gcc: error: unrecognized command line option '-bad'
ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/cvexpr.exp.
ERROR: can't read "use_gdb_stub": no such variable
...
This is triggered in a part of the test that claims to require no debug
information, but uses the exec containing either dwarf or ctf.
Fix this by preparing another executable compiled with nodebug, and using
that one instead.
Also use with_test_prefix to mark the nodebug part, such that we have:
...
gdb compile failed, gcc: error: unrecognized command line option '-bad'
UNTESTED: gdb.base/cvexpr.exp: dwarf: failed to prepare
gdb compile failed, gcc: error: unrecognized command line option '-bad'
UNTESTED: gdb.base/cvexpr.exp: nodebug: failed to prepare
...
Tested on x86_64-linux.
|
|
Fix:
...
DUPLICATE: gdb.base/cvexpr.exp: ptype int * restrict
...
using with_test_prefix.
Tested on x86_64-linux.
|
|
When running test-case gdb.base/call-sc.exp with target board unix/-bad, I
get:
...
gdb compile failed, gcc: error: unrecognized command line option '-bad'
UNTESTED: gdb.base/call-sc.exp: failed to prepare
ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/call-sc.exp.
ERROR: can't read "use_gdb_stub": no such variable
...
Fix this by checking the compilation result.
Fix the resulting DUPLICATE:
...
DUPLICATE: gdb.base/call-sc.exp: failed to prepare
...
using with_test_prefix.
Tested on x86_64-linux.
|
|
The effect of:
...
untested "y.exp"
...
in a gdb.x/y.exp is:
...
UNTESTED: gdb.x/y.exp: y.exp
...
which is a bit pointless.
Replace these untested messages in gdb.mi/*.exp with the usual "failed to
compile".
Likewise for an:
...
untested $testname
...
where the variable is undefined.
Tested on x86_64-linux.
|
|
containing LTO information.
* objcopy.c (filter_symbols): Fail if attempting to dredefine
symbols in an LTO object file.
|
|
On ubuntu 18.04.5, I run into:
...
(gdb) mt print objfiles dwindex^M
^M
Object file build/gdb/testsuite/outputs/gdb.rust/dwindex/dwindex: \
Objfile at 0x55dab0b87a50, bfd at 0x55dab0b0cfa0, 1095 minsyms^M
^M
Psymtabs:^M
vendor/compiler_builtins/src/int/specialized_div_rem/mod.rs at 0x55dab0db0720^M
...
library/std/src/sys/unix/stdio.rs at 0x55dab0d96320^M
ERROR: internal buffer is full.
UNRESOLVED: gdb.rust/dwindex.exp: check if index present
...
Fix this by using -lbl in proc ensure_gdb_index.
Tested on x86_64-linux.
|
|
Add elfcore_grok_solaris_note function that enables to
obtain process status, register values, and program info
from Solaris's core files.
bfd/
* elf.c (elfcore_grok_solaris_note): Solaris specific ELF
note parser. Better GDB's coredump analysis on Solaris...
(elfcore_grok_solaris_note_impl): New function.
(elfcore_grok_solaris_prstatus): New function.
(elfcore_grok_solaris_info): New function.
(elfcore_grok_solaris_lwpstatus): New function.
(elf_parse_notes): Added "CORE" groker element.
include/
* elf/common.h: Add note segment constants for core files on
Solaris systems.
|
|
* readelf.c (get_openbsd_elfcore_note_type): New function.
(process_note): Add support for OpenBSD core notes.
|
|
|
|
When running test-case gdb.base/break-interp.exp on openSUSE Leap 42.3, I get:
...
(gdb) info addr dl_main^M
Symbol "dl_main" is at 0x1750 in a file compiled without debugging.^M
(gdb) FAIL: gdb.base/break-interp.exp: info addr dl_main
...
while the regexp expects "Symbol \"dl_main\" is a function at address $hex\\."
Fix this by also accepting this variant.
Tested on x86_64-linux.
|
|
PR binutils/27202
* testsuite/gas/elf/dwarf-5-loc0.d: New file.
* testsuite/gas/elf/dwarf-5-loc0.s: Likewise.
* testsuite/gas/elf/elf.exp: Run dwarf-5-loc0.
|
