According to the riscv psabi, R_RISCV_SUB6 only allows 6 least significant
bits are valid, but since binutils implementation, we usually get 8 bits
field for it. That means, the high 2 bits could be other field and have
different purpose. Therefore, we should filter the 8 bits to 6 bits before
calculate, and then only encode the valid 6 bits back. By the way, we also
need the out-of-range check for R_RISCV_SUB6, and the overflow checks for
all R_RISCV_ADD/SUB/SET relocations, but we can add them in the future patches.
Passing riscv-gnu-toolchain regressions.
bfd/ChangeLog:
* elfnn-riscv.c (riscv_elf_relocate_section): Take the R_RISCV_SUB6
lower 6 bits as the significant bit.
* elfxx-riscv.c (riscv_elf_add_sub_reloc): Likewise.
This uses custom collect/supply regset handlers which pass the TLS
register number from the gdbarch_tdep as the base register number.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This uses custom collect/supply regset handlers which pass the TLS
register number from the gdbarch_tdep as the base register number.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This is needed to permit using the helpers for register sets with a
variable base. In particular regnum needs to be converted into a
relative register number before passed to regcache_map_supplies.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
fbsd-nat includes various helper routines for fetching and storing
register sets via ptrace where the register set is described by a
regset. These helper routines directly invoke the
supply/collect_regset regcache methods which doesn't permit a regset
to provide custom logic when fetching or storing a register set.
Instead, just use the function pointers from the struct regset
directly.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Some register sets described by an array of regcache_map_entry
structures do not have fixed register numbers in their associated
architecture but do describe a block of registers whose numbers are at
fixed offsets relative to some base register value. An example of
this are the TLS register sets for the ARM and AArch64 architectures.
Currently OS-specific architectures create register maps and register
sets dynamically using the register base number. However, this
requires duplicating the code to create the register map and register
set. To reduce duplication, add variants of the collect_regset and
supply_regset regcache methods which accept a base register number.
For valid register map entries (i.e. not REGCACHE_MAP_SKIP), add this
base register number to the value from the map entry to determine the
final register number.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The aim here is to improve readelf handling of large 64-bit object
files on LLP64 hosts (Windows) where long is only 32 bits. The patch
changes more than just file offsets. Addresses and sizes are also
changed to avoid "long". Most places get to use uint64_t even where
size_t may be more appropriate, because that allows some overflow
checks to be implemented easily (*alloc changes).
* dwarf.c (cmalloc, xcmalloc, xcrealloc, xcalloc2): Make nmemb
parameter uint64_t.
* dwarf.h: Update prototypes.
(struct dwarf_section): Make num_relocs uint64_t.
* elfcomm.c (setup_archive): Update error format.
* elfcomm.h (struct archive_info): Make sym_size, longnames_size,
nested_member_origin, next_arhdr_offset uint64_t.
* readelf.c (struct filedata): Make archive_file_offset,
archive_file_size, string_table_length, dynamic_addr,
dynamic_nent, dynamic_strings_length, num_dynamic_syms,
dynamic_syminfo_offset uint64_t.
(many functions): Replace uses of "unsigned long" with
"uint64_t" or "size_t".
Replace the macros with a small wrapper function that verifies the fseek
offset arg isn't overlarge.
* readelf.c (FSEEK_FUNC): Delete, replace uses with..
(fseek64): ..this new function.
(process_program_headers): Don't cast p_offset to long.
As part of the rebase of the patch, I managed to loose the local
changes I had for the comments from Tomas in
https://sourceware.org/pipermail/gdb-patches/2022-November/193413.html
This patch corrects the obvious two typos.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Integrate back checks for fseeko{,64} into configure.ac, so
that regeneration works.
binutils/
* configure.ac: Add fseeko, fseeko64 checks.
* configure: Regenerate.
This patch changes the address for "isa_config" auxiliary register
from 0xC2 to the correct value 0xC1. Moreover, it only exists in
arc700+ and not all ARCs.
opcodes/ChangeLog:
* arc-regs.h: Change isa_config address to 0xc1.
isa_config exists for ARC700 and ARCV2 and not ARCALL.
With the recent changes to the dwarf assembler, there is no longer a
need to test for gcc in gdb.dwarf2/clang-cli-macro.exp and mark it as
untested. This commit removes that logic.
Once again: Old enough glibc has an (unguarded) declaration of index()
in string.h, which triggers a "shadows a global declaration" warning
with our choice of wanring level and with at least some gcc versions.
Changes readelf to make use first of fseeko64 and then fseeko,
depending on which of those is available. If neither is available,
reverts to the previous behavior of using fseek.
This is necessary when building readelf for LLP64 systems, where a
long will only be 32 bits wide. If the elf file in question is >= 2 GiB,
that is greater than the max long value and therefore fseek will fail
indicating that the offset is negative. On such systems, making use of
fseeko64 or fseeko will result in the ability so seek past the 2 GiB
max long boundary.
Note that large archive handling in readelf remains to be fixed.
Remove this code dating back to commit 98790d3a95 entirely, what it
was trying to do is done elsewhere.
PR ld/29761
* elflink.c (elf_link_output_symstrtab): Don't handle symbols
in SEC_EXCLUDE sections here.
The test py-objfile.exp unloads the current file while debugging the process.
This results in bpstat bs->b->loc to become nullptr.
Handle this case in breakpoint.c:bpstat_locno.
Note: GDB crashes on this problem with an internal error,
but the end of gdb summary shows:
...
=== gdb Summary ===
# of expected passes 36
The output also does not contain a 'FAIL:'.
After the fix, the nr of expected passes increased.
In the gdb.log output, one can see:
...
Fatal signal: Segmentation fault
----- Backtrace -----
0x55698905c5b9 gdb_internal_backtrace_1
../../binutils-gdb/gdb/bt-utils.c:122
0x55698905c5b9 _Z22gdb_internal_backtracev
...
ERROR: Couldn't send python print(objfile.filename) to GDB.
ERROR: : spawn id exp9 not open
while executing
"expect {
-i exp9 -timeout 10
-re ".*A problem internal to GDB has been detected" {
fail "$message (GDB internal error)"
gdb_internal_error..."
("uplevel" body line 1)
invoked from within
....
Wondering if it might be possible to improve gdb_test to have
gdb_test "python print(objfile.filename)" "None" \
"objfile.filename after objfile is unloaded"
reporting a failed result instead of just producing the internal error.
If the commands of the bpstat bs contain commands such as step or next or
continue, the BS and its commands are freed by execute_control_command.
So, we cannot remember the BS that was printed. Instead, remember
the bpnum and locno.
Regtested on debian/amd64 and re-run a few tests under valgrind.
step-over-syscall.exp has some specific tests for gdbserver.
The regexp matching breakpoint hit must take the added locno into account.
Test re-run in 3 modes (normal, native-gdbserver and native-extended-gdbserver).
PR 29764
gas * testsuite/gas/arm/cpu-cortex-a76ae.d: Add arm prefix to the -m
option passed to objdump.
* testsuite/gas/arm/cpu-cortex-a77.d: Likewise.
* testsuite/gas/aarch64/cpu-cortex-a76ae.d: Add aarch64 prefix to
the -m option passed to objdump.
* testsuite/gas/aarch64/cpu-cortex-a77.d: Likewise.
bfd * cpu-arm.c (scan): Accept machine names prefixed with "arm:".
* cpu-aarch64.c (scan): Accept machine names prefixed with "aarch64:".
bin * doc/binutils.texi (objdump): Note that the -m option supports
the <architecture>:<machine> syntax.
For targets with secext, msp and psp can be seen as an alias for one
of msp_s, msp_ns, psp_s or psp_ns.
Without this patch, sp might be secure, but msp or psp is non-secure
(this state can not happen in the hardware).
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
For targets with secext, msp and psp can be seen as an alias for one
of msp_s, msp_ns, psp_s or psp_ns. When switching active sp, the
corresponding msp/psp needs to be switched too.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Some gdb stubs may not describe the type for vector registers in the
tdesc-xml and only send bitsize="128", gdb can't deal with a reg
with default type int with bitsize==128. So Just return csky_vector_type()
for vector resgisters.
gdbsupport compilation badly fails with GCC 12 on Solaris, with errors
like
../gnulib/config.h:1693:72: error: ‘malloc’ attribute argument 1 is ambiguous
1693 | # define _GL_ATTRIBUTE_DEALLOC(f, i) __attribute__ ((__malloc__ (f, i)))
| ^
../gnulib/config.h:1693:72: note: use a cast to the expected type to disambiguate
We've not yet been able to determine where the ambiguity actually lies,
so this patch works around the issue by disabling _GL_ATTRIBUTE_DEALLOC
on Solaris, at least as a workaround for GDB 13.
As Tom suggested in the PR, this is done using our infrastructure for
local gnulib patches.
Tested on sparcv9-sun-solaris2.11, amd64-pc-solaris2.11, and
x86_64-pc-linux-gnu.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
sol-thread.c fails to compile on 32-bit Solaris: there are several
instances of
In file included from /vol/src/gnu/gdb/hg/master/local/gdb/../gdbsupport/common-defs.h:203,
from /vol/src/gnu/gdb/hg/master/local/gdb/defs.h:28,
from /vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:51:
/vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c: In member function ‘virtual void sol_thread_target::resume(ptid_t, int, gdb_signal)’:
/vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:416:20: error: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘ULONGEST’ {aka ‘long long unsigned int’} [-Werror=format=]
416 | warning (_("Specified thread %ld seems to have terminated"),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/vol/src/gnu/gdb/hg/master/local/gdb/../gdbsupport/gdb_locale.h:28:29:
note: in definition of macro ‘_’
28 | # define _(String) gettext (String)
| ^~~~~~
/vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:416:40: note: format
string is defined here
416 | warning (_("Specified thread %ld seems to have terminated"),
| ~~^
| |
| long int
| %lld
Fixed by using pulongest () instead.
Tested on i386-pc-solaris2.11, amd64-pc-solaris2.11,
sparc-sun-solaris2.11, and sparcv9-sun-solaris2.11 (together with
Simon's patch for PR build/29798).
ctxobj.exp fails randomly when computer is loaded.
With the addition of $gdb_prompt in the regexp testing for breakpoint hit,
I could not make it fail anymore.
Also fixed a typo in a comment.
This implements the request given in PR breakpoints/12464.
Before this patch, when a breakpoint that has multiple locations is reached,
GDB printed:
Thread 1 "zeoes" hit Breakpoint 1, some_func () at somefunc1.c:5
This patch changes the message so that bkpt_print_id prints the precise
encountered breakpoint:
Thread 1 "zeoes" hit Breakpoint 1.2, some_func () at somefunc1.c:5
In mi mode, bkpt_print_id also (optionally) prints a new table field "locno":
locno is printed when the breakpoint hit has more than one location.
Note that according to the GDB user manual node 'GDB/MI Development and Front
Ends', it is ok to add new fields without changing the MI version.
Also, when a breakpoint is reached, the convenience variables
$_hit_bpnum and $_hit_locno are set to the encountered breakpoint number
and location number.
$_hit_bpnum and $_hit_locno can a.o. be used in the command list of a
breakpoint, to disable the specific encountered breakpoint, e.g.
disable $_hit_bpnum.$_hit_locno
In case the breakpoint has only one location, $_hit_locno is set to
the value 1, so as to allow a command such as:
disable $_hit_bpnum.$_hit_locno
to disable the breakpoint even when the breakpoint has only one location.
This also fixes a strange behaviour: when a breakpoint X has only
one location,
enable|disable X.1
is accepted but transforms the breakpoint in a multiple locations
breakpoint having only one location.
The changes in RFA v4 handle the comments of Tom Tromey:
- Changed convenience var names from $bkptno/$locno to
$_hit_bpnum/$_hit_locno.
- updated the tests and user manual accordingly.
User manual also explictly describes that $_hit_locno is set to 1
for a breakpoint with a single location.
- The variable values are now set in bpstat_do_actions_1 so that
they are set for silent breakpoints, and when several breakpoints
are hit at the same time, that the variables are set to the printed
breakpoint.
The changes in RFA v3 handle the additional comments of Eli:
GDB/NEW:
- Use max 80-column
- Use 'code location' instead of 'location'.
- Fix typo $bkpno
- Ensure that disable $bkptno and disable $bkptno.$locno have
each their explanation inthe example
- Reworded the 'breakpoint-hit' paragraph.
gdb.texinfo:
- Use 'code location' instead of 'location'.
- Add a note to clarify the distinction between $bkptno and $bpnum.
- Use @kbd instead of examples with only one command.
Compared to RFA v1, the changes in v2 handle the comments given by
Keith Seitz and Eli Zaretskii:
- Use %s for the result of paddress
- Use bkptno_numopt_re instead of 2 different -re cases
- use C@t{++}
- Add index entries for $bkptno and $locno
- Added an example for "locno" in the mi interface
- Added examples in the Break command manual.
This commit adds 'Ssstateen' extension, which is a supervisor-visible view
of the 'Smstateen' extension. It means, this extension implements sstateen*
and hstateen* CSRs of the 'Smstateen' extension.
Note that 'Smstateen' extension itself is unchanged but due to
implementation simplicity, it is implemented so that 'Smstateen' implies
'Ssstateen' (just like 'M' implies 'Zmmul').
This is based on the latest version of RISC-V Profiles
(version 0.9-draft, Frozen):
<226b7f6430>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_implicit_subsets): Update implication rules.
(riscv_supported_std_s_ext) Add 'Ssstateen' extension.
gas/ChangeLog:
* config/tc-riscv.c (enum riscv_csr_class): Rename
CSR_CLASS_SMSTATEEN_AND_H{,_32} to CSR_CLASS_SSSTATEEN_...
Add CSR_CLASS_SSSTATEEN.
(riscv_csr_address): Support new/renamed CSR classes.
* testsuite/gas/riscv/csr.s: Add 'Ssstateen' extension to comment.
* testsuite/gas/riscv/csr-version-1p9p1.l: Reflect changes to
error messages.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
* testsuite/gas/riscv/ssstateen-csr.s: Test for 'Ssstateen' CSRs.
* testsuite/gas/riscv/ssstateen-csr.d: Likewise.
* testsuite/gas/riscv/smstateen-csr-s.d: Test to make sure that
supervisor/hypervisor part of 'Smstateen' CSRs are accessible from
'RV32IH_Smstateen', not just from 'RV32IH_Ssstateen' that is tested
in ssstateen-csr.d.
include/ChangeLog:
* opcode/riscv-opc.h: Update DECLARE_CSR declarations with
new CSR classes.
Commit 4855cbdc3d ("gdbserver/linux-x86: make is_64bit_tdesc accept
thread as a parameter") caused this when building in 32 bits / i386
mode:
CXX linux-x86-low.o
In file included from /home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc:24:
/home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc: In member function ‘virtual int x86_target::low_get_thread_area(int, CORE_ADDR*)’:
/home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc:357:47: error: ‘lwp’ was not declared in this scope
357 | struct thread_info *thr = get_lwp_thread (lwp);
| ^~~
/home/smarchi/src/binutils-gdb/gdbserver/linux-low.h:709:31: note: in definition of macro ‘get_lwp_thread’
709 | #define get_lwp_thread(lwp) ((lwp)->thread)
| ^~~
This is because it moved the lwp variable declaration inside the
__x86_64__ guard, making it unavailable when building in 32 bits mode.
Move the lwp variable outside of the __x86_64__ region.
Change-Id: I7fa3938c6b44b345c27a52c8b8d3ea12aba53e05
The following patch ("gdbserver: switch to right process in
find_one_thread") makes it so find_one_thread calls into libthread_db
with a current process but no current thread. This tripped on ps_getpid
using current_thread in order to get the process' pid. Get the pid from
`current_process ()` instead, which removes the need to have a current
thread. Eventually, it would be good to get it from the
gdb_ps_prochandle_t structure, to avoid the need for a current process
as well.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I9d2fae266419199a2fbc2fde0a5104c6e0dbd2d5
ps_get_thread_area receives as a parameter the lwpid it must work on.
It then calls is_64bit_tdesc, which uses the current_thread as the
thread to work on. However, it is not said that both are the same.
This became a problem when working in a following patch that makes
find_one_thread switch to a process but to no thread (current_thread ==
nullptr). When libthread_db needed to get the thread area,
is_64bit_tdesc would try to get the regcache of a nullptr thread.
Fix that by making is_64bit_tdesc accept the thread to work on as a
parameter. Find the right thread from the context, when possible (when
we know the lwpid to work on). Otherwise, pass "current_thread", to
retain the existing behavior.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I44394d6be92392fa28de71982fd04517ce8a3007
Just a small optimization, it's not necessary to recompute lwp at each
iteration.
While at it, change the variable type to long, as ptid_t::lwp returns a
long.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I181670ce1f90b59cb09ea4899367750be2ad9105
Currently, FinishBreakpoints are set at the return address of a frame based on
the `finish' command, and are meant to be temporary breakpoints. However, they
are not being cleaned up after use, as reported in PR python/18655. This was
happening because the disposition of the breakpoint was not being set
correctly.
This commit fixes this issue by correctly setting the disposition in the
post-stop hook of the breakpoint. It also adds a test to ensure this feature
isn't regressed in the future.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18655
When building on Ubuntu 22.04, gcc 12, x86-64 with -m32 and -O2, I get:
CXX symtab.o
/home/smarchi/src/binutils-gdb/gdb/symtab.c: In member function ‘std::vector<symbol_search> global_symbol_searcher::search() const’:
/home/smarchi/src/binutils-gdb/gdb/symtab.c:4961:44: error: ‘__builtin___sprintf_chk’ may write a terminating nul past the end of the destination [-Werror=format-overflow=]
4961 | sprintf (tmp, "operator%.*s%s", fix, " ", opname);
| ^
In file included from /usr/include/stdio.h:894,
from ../gnulib/import/stdio.h:43,
from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/common-defs.h:86,
from /home/smarchi/src/binutils-gdb/gdb/defs.h:28,
from /home/smarchi/src/binutils-gdb/gdb/symtab.c:20:
In function ‘int sprintf(char*, const char*, ...)’,
inlined from ‘std::vector<symbol_search> global_symbol_searcher::search() const’ at /home/smarchi/src/binutils-gdb/gdb/symtab.c:4961:16:
/usr/include/i386-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 9 and 2147483648 bytes into a destination of size 2147483647
38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
40 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
PR build/29798 shows a similar error message but on Solaris.
Work around that by using string_printf. It is a good thing to get rid
of the alloca anyway.
Change-Id: Ifbac11fee3062ad7f134d596b4e2229dc5d166f9
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29798
Convert the gdb.cp/call-method-register.exp test to make use of the
DWARF assembler.
The existing gdb.cp/call-method-register.exp test relies on a GCC
extension - forcing a local variable into a particular named register.
This means that the test will only work with Clang, and, as we have to
name the register into which the variable will be placed, will only
work for those targets where we've selected a suitable register,
currently this is x86-64, i386, and ppc64.
By switching to the DWARF assembler, the test will work with gcc and
clang, and should work on most, if not all, architectures.
The test creates a small structure, something that can fit within a
register, and then tries to call a method on the structure from within
GDB. This should fail because GDB can't take the address of the in
register structure (for the `this` pointer).
As the test is for a failure case, then we don't really care _which_
register the structure is in, and I take advantage of this for the
DWARF assembler test, I just declare that the variable is in
DW_OP_reg0, whatever that might be. I've tested the new test on
x86-64, ppc, aarch64, and risc-v, and the test runs, and passes on all
these architectures, which is already more than we used to cover.
Additionally, on x86-64, I've tested with Clang and gcc, and the test
runs and passed with both compilers.
Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
The gdb.debuginfod/fetch_src_and_symbols.exp test is showing a single
failure when run with some older versions of Clang, e.g. 9.0.1.
The problem appears to be with Clang's generated line table. The test
source looks like this:
int
main()
{
asm ("main_label: .globl main_label");
return 0;
}
In GDB, when we 'start', we expect to stop at the 'return 0;' line.
This is the behaviour when the compiler is gcc, or later versions of
Clang.
However, with Clang 9.0.2, I see GDB stop on the 'asm' line.
In this commit I'll fix this issue by placing a breakpoint on the
return line, and then using gdb_continue_to_breakpoint to ensure we
have stopped in the correct place.
Of course, using gdb_continue_to_breakpoint will only work if we are
not already stopped at the breakpoint location, so I've added some
filler work before the 'return 0;' line. With this done we can use
gdb_continue_to_breakpoint in all cases.
As a result of adding the new filler work, one of the later tests,
that used the 'list' command, no longer see the correct expected
output (the top line of the source file is no longer included in the
output). I've fixed this by listing a known specific line, the test
is checking that GDB managed to find the source file, it doesn't
matter which source line we list, as long as we can list something.
The test gdb.debuginfod/fetch_src_and_symbols.exp uses a source file
named main.c. I can't see any particular reason why the file is named
as such.
Usually test source files are named after the test script.
This commit just renames the source file inline with the test script,
and updates the call to standard_testfile (removing the reference to
main.c).
There's no particular reason for this change other than seeing the
file named main.c made me thing that the source file must be shared
with some other test (it isn't).
There should be no change in what is tested after this commit.
I noticed that the gdb.debuginfod/fetch_src_and_symbols.exp test was
failing when run with Clang as the compiler.
This test relies on the compiled binaries having a build-id within
them. For GCC, really GNU ld, the default is to always include a
build-id.
When compiling with Clang though, the default is for no build-id.
I did consider *always* turning on the build-id feature when the
compiler is Clang, but that felt a little weird.
Instead, I propose that we add a new 'build-id' compiler option to
gdb_compile, this flag indicates that the test _requires_ a build-id.
In gcc_compile we can then add the required flags if the compiler is
Clang so that we do get a build-id.
With this change the gdb.debuginfod/fetch_src_and_symbols.exp test
now (mostly) passes with Clang 9.0.1 and 15.0.2, and still passes with
gcc. The 'mostly' part is an unrelated issue, and will be addressed
in a later commit in this series.
Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
I noticed that the gdb.compile/compile-ops.exp test was failing when
run with Clang as the compiler.
This test makes use of the DWARF assembler, and, it turns out, uses
a technique which is not portable to Clang. This problem is
described in the comment on the function_range proc in lib/dwarf.exp,
the explanation is:
# If the compiler is gcc, we can do the following to get function start
# and end address too:
#
# asm ("func_start: .globl func_start");
# static void func (void) {}
# asm ("func_end: .globl func_end");
#
# however, this isn't portable, because other compilers, such as clang,
# may not guarantee the order of global asms and function. The code
# becomes:
#
# asm ("func_start: .globl func_start");
# asm ("func_end: .globl func_end");
# static void func (void) {}
These start/end labels are used for computing the function start, end,
and length. The portable solution is to place a label within the
function, like this:
# int main (void)
# {
# asm ("main_label: .globl main_label");
# return 0;
# }
And make use of 'proc function_range' (from lib/dwarf.exp).
So, that's what I do in this commit.
One consequence of this change is that we need to compile the source
file, and have it loaded into a GDB session, before calling
function_range, so I've added an early call to prepare_for_testing.
Additionally, this test script was generating the DWARF assembler into
a file called gdbjit-ops.S, I suspect a copy and paste issue there, so
I've switched this to use compile-ops-dbg.S instead, which is more
inline with what other DWARF assembler tests do.
The only other change, which might be a problem, is that I also
deleted these two lines from the source file:
asm (".section \".text\"");
asm (".balign 8");
These lines were setting the alignment of the .text section. What I
don't know is whether this was significant or not. If it is
significant, then I can't see why.
On x86-64, the test still passes fine without these lines, but that
doesn't mean the test wont start failing on some other architecture.
Still, I figure, lets remove them, then, if/when we find a test that
starts failing, we can add the lines back, along with an explanation
for why the extra alignment is required.
But, if people would prefer to be more conservative, then I'm happy to
just add the lines back.
Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
I noticed that the test gdb.trace/unavailable-dwarf-piece.exp was
failing when run with Clang. Or rather, the test was not running as
the test executable failed to compile.
The problem is that Clang was emitting this warning:
warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument]
This warning is emitted when compiling the assembler file generated
by the DWARF assembler.
Most DWARF assembler tests generate the assembler file into a file
with the '.S' extension. However, this particular test uses a '.s'
extension.
Now a .S file will be passed through the preprocessor, while a .s will
be sent straight to the assembler. My guess is that Clang doesn't
support the -fdiagnostics-color=never option for the assembler, but
does for the preprocessor.
That's a little annoying, but easily worked around. We don't care if
our assembler file is passed through the preprocessor, so, in this
commit, I just change the file extension from .s to .S, and the
problem is fixed.
Currently, the unavailable-dwarf-piece.exp script names the assembler
file using standard_output_file, in this commit I've switched to make
use of standard_testfile, as that seems to be the more common way of
doing this sort of thing.
With these changes the test now passes with Clang 9.0.1 and 15.0.2,
and also still passes with gcc.
Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
Two tests make the claim that the DWARF assembler requires gcc,
however, this isn't true. I think at one point, when the DWARF
assembler was first added, we did use some techniques that were not
portable (see the comments in lib/dwarf.exp on function_range for
details), however, I think most DWARF assembler tests will now work
fine with Clang.
The two tests that I modify in this commit both work fine with Clang,
at least, I've tested with Clang 9.0.1 and 15.0.2, and don't see any
problems, so I'm removing the early return logic that stops these
tests from running with Clang.
Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
