| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
[Sending to binutils, gdb-patches and gcc-patches, since it touches the
top-level Makefile/configure]
I have my debuginfod library installed in a non-standard location
(/opt/debuginfod), which requires me to set
PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config. If I just set it during
configure:
$ PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config ./configure --with-debuginfod
$ make
or
$ ./configure --with-debuginfod PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config
$ make
Then PKG_CONFIG_PATH is only present (and ignored) during the top-level
configure. When running make (which runs gdb's and binutils'
configure), PKG_CONFIG_PATH is not set, which results in their configure
script not finding the library:
checking for libdebuginfod >= 0.179... no
configure: error: "--with-debuginfod was given, but libdebuginfod is missing or unusable."
Change the top-level configure/Makefile system to capture the value
passed when configuring the top-level and pass it down to
subdirectories (similar to CFLAGS, LDFLAGS, etc).
I don't know much about the top-level build system, so I really don't
know if I did this correctly. The changes are:
- Use AC_SUBST(PKG_CONFIG_PATH) in configure.ac, so that
@PKG_CONFIG_PATH@ gets replaced with the actual PKG_CONFIG_PATH value
in config files (i.e. Makefile)
- Add a PKG_CONFIG_PATH Makefile variable in Makefile.tpl, initialized
to @PKG_CONFIG_PATH@
- Add PKG_CONFIG_PATH to HOST_EXPORTS in Makefile.tpl, which are the
variables set when running the sub-configures
I initially added PKG_CONFIG_PATH to flags_to_pass, in Makefile.def, but
I don't think it's needed. AFAIU, this defines the flags to pass down
when calling "make" in subdirectories. We only need PKG_CONFIG_PATH to
be passed down during configure. After that, it's captured in
gdb/config.status, so even if a "make" causes a re-configure later
(because gdb/configure has changed, for example), the PKG_CONFIG_PATH
value will be remembered.
ChangeLog:
* configure.ac: Add AC_SUBST(PKG_CONFIG_PATH).
* configure: Re-generate.
* Makefile.tpl (HOST_EXPORTS): Pass PKG_CONFIG_PATH.
(PKG_CONFIG_PATH): New.
* Makefile.in: Re-generate.
Change-Id: I91138dfca41c43b05e53e445f62e4b27882536bf
|
|
I see this failure:
(gdb) run ^M
Starting program: /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-inline-param/dw2-inline-param ^M
Warning:^M
Cannot insert breakpoint 1.^M
Cannot access memory at address 0x113b^M
^M
(gdb) FAIL: gdb.dwarf2/dw2-inline-param.exp: runto: run to *0x113b
The test loads the binary in GDB, grabs the address of a symbol, strips
the binary, reloads it in GDB, runs the program, and then tries to place
a breakpoint at that address. The problem is that the binary is built
as position independent, so the address GDB grabs in the first place
isn't where the code ends up after running.
Fix this by linking the binary as non-position-independent. The
alternative would be to compute the relocated address where to place the
breakpoint, but that's not very straightforward, unfortunately.
I was confused for a while, I was trying to load the binary in GDB
manually to get the symbol address, but GDB was telling me the symbol
could not be found. Meanwhile, it clearly worked in gdb.log. The thing
is that GDB strips the binary in-place, so we don't have access to the
intermediary binary with symbols. Change the test to output the
stripped binary to a separate file instead.
Change-Id: I66c56293df71b1ff49cf748d6784bd0e935211ba
|
|
Formalise what ought to be obvious. The top level of the binutils-gdb
repository isn't owned by binutils.
* MAINTAINERS: Spelling fix. GDB global maintainer rights.
|
|
Add the print of the base-class of an extended type to the output of
ptype. This requires the Fortran compiler to emit DW_AT_inheritance
for the extended type.
Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
|
|
Fortran 2003 supports type extension. This patch allows access
to inherited members by using their fully qualified name as described
in the Fortran standard.
In doing so the patch also fixes a bug in GDB when trying to access the
members of a base class in a derived class via the derived class' base
class member.
This patch fixes PR22497 and PR26373 on GDB side.
Using the example Fortran program from PR22497
program mvce
implicit none
type :: my_type
integer :: my_int
end type my_type
type, extends(my_type) :: extended_type
end type extended_type
type(my_type) :: foo
type(extended_type) :: bar
foo%my_int = 0
bar%my_int = 1
print*, foo, bar
end program mvce
and running this with GDB and setting a BP at 17:
Before:
(gdb) p bar%my_type
A syntax error in expression, near `my_type'.
(gdb) p bar%my_int
There is no member named my_int.
(gdb) p bar%my_type%my_int
A syntax error in expression, near `my_type%my_int'.
(gdb) p bar
$1 = ( my_type = ( my_int = 1 ) )
After:
(gdb) p bar%my_type
$1 = ( my_int = 1 )
(gdb) p bar%my_int
$2 = 1 # this line requires DW_TAG_inheritance to work
(gdb) p bar%my_type%my_int
$3 = 1
(gdb) p bar
$4 = ( my_type = ( my_int = 1 ) )
In the above example "p bar%my_int" requires the compiler to emit
information about the inheritance relationship between extended_type
and my_type which gfortran and flang currently do not de. The
respective issue gcc/49475 has been put as kfail.
Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26373
https://sourceware.org/bugzilla/show_bug.cgi?id=22497
|
|
Signed-off-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
|
|
Straightforward change, return an std::string instead of a
gdb::unique_xmalloc_ptr<char>. No behavior change expected.
Change-Id: Ia5e94c94221c35f978bb1b7bdffbff7209e0520e
|
|
|
|
Commit:
commit df7a7bdd9766adebc6b117c31bc617d81c1efd43
Date: Thu Mar 17 18:56:23 2022 +0000
gdb: add support for Fortran's ASSUMED RANK arrays
Added support for Fortran assumed rank arrays. Unfortunately, this
commit contained a bug that means though GDB can correctly calculate
the rank of an assumed rank array, GDB can't fetch the contents of an
assumed rank array.
The history of this patch can be seen on the mailing list here:
https://sourceware.org/pipermail/gdb-patches/2022-January/185306.html
The patches that were finally committed can be found here:
https://sourceware.org/pipermail/gdb-patches/2022-March/186906.html
The original patches did support fetching the array contents, it was
only the later series that introduced the regression.
The problem is that when calculating the array rank the result is a
count of the number of ranks, i.e. this is a 1 based result, 1, 2, 3,
etc.
In contrast, when computing the details of any particular rank the
value passed to the DWARF expression evaluator should be a 0 based
rank offset, i.e. a 0 based number, 0, 1, 2, etc.
In the patches that were originally merged, this was not the case, and
we were passing the 1 based rank number to the expression evaluator,
e.g. passing 1 when we should pass 0, 2 when we should pass 1, etc.
As a result the DWARF expression evaluator was reading the
wrong (undefined) memory, and returning garbage results.
In this commit I have extended the test case to cover checking the
array contents, I've then ensured we make use of the correct rank
value, and extended some comments, and added or adjusted some asserts
as appropriate.
|
|
Make gdb_compile handle a new "macros" option, which makes it pass the
appropriate flag to make the compiler include macro information in the
debug info. This will help simplify tests using macros, reduce
redundant code, and make it easier to add support for a new compiler.
Right now it only handles clang specially (using -fdebug-macro) and
falls back to -g3 otherwise (which works for gcc). Other compilers can
be added as needed.
There are some tests that are currently skipped if the compiler is nor
gcc nor clang. After this patch, the tests will attempt to run (the -g3
fall back will be used). That gives a chance to people using other
compilers to notice something is wrong and maybe add support for their
compiler. If it is needed to support a compiler that doesn't have a way
to include macro information, then we can always introduce a
"skip_macro_tests" that can be used to skip over them.
Change-Id: I50cd6ab1bfbb478c1005486408e214b551364c9b
|
|
It is only set, never used.
Change-Id: Ia46ed2f9da243b0ccfc4588c1b57be2a0f3939de
|
|
On openSUSE Tumbleweed I run into:
...
FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
...
The problem is that the libthread_db message occurs at a location where it's
not expected:
...
Starting program: outputs/gdb.base/annota1/annota1 ^M
^M
^Z^Zstarting^M
^M
^Z^Zframes-invalid^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
^M
^Z^Zbreakpoints-invalid^M
^M
...
Fix this by making the matching more robust:
- rewrite the regexp such that each annotation is on a single line,
starting with \r\n\032\032 and ending with \r\n
- add a regexp variable optional_re, that matches all possible optional
output, and use it as a separator in the first part of the regexp
Tested on x86_64-linux.
|
|
By calling `uplevel $body` in the program proc (a pattern we use at many
places), we can get rid of curly braces around each line number program
directive. That seems like a nice small improvement to me.
Change-Id: Ib327edcbffbd4c23a08614adee56c12ea25ebc0b
|
|
These variables seem to be unused, remove them.
Change-Id: I7d613d9d35735930ee78b2c348943c73a702afbb
|
|
Same idea as previous patch, but for symtab::pspace.
Change-Id: I1023abe622bea75ef648c6a97a01b53775d4104d
|
|
Same idea as previous patch, but for symtab::objfile. I find
it clearer without this wrapper, as it shows that the objfile is
common to all symtabs of a given compunit. Otherwise, you could think
that each symtab (of a given compunit) can have a specific objfile.
Change-Id: Ifc0dbc7ec31a06eefa2787c921196949d5a6fcc6
|
|
symtab::blockvector is a wrapper around compunit_symtab::blockvector.
It is a bit misleadnig, as it gives the impression that a symtab has a
blockvector. Remove it, change all users to fetch the blockvector
through the compunit instead.
Change-Id: Ibd062cd7926112a60d52899dff9224591cbdeebf
|
|
I think the symtab::dirname method is bogus, or at least very
misleading. It makes you think that it returns the directory that was
used to find that symtab's file during compilation (i.e. the directory
the file refers to in the DWARF line header file table), or the
directory part of the symtab's filename maybe. In fact, it returns the
compilation unit's directory, which is the CWD of the compiler, at
compilation time. At least for DWARF, if the symtab's filename is
relative, it will be relative to that directory. But if the symtab's
filename is absolute, then the directory returned by symtab::dirname has
nothing to do with the symtab's filename.
Remove symtab::dirname to avoid this confusion, change all users to
fetch the same information through the compunit. At least, it will be
clear that this is a compunit property, not a symtab property.
Change-Id: I2894c3bf3789d7359a676db3c58be2c10763f5f0
|
|
Change gdb_breakpoint to accept a linespec, not just a function. In
fact, no behavior changes are necessary, this only changes the parameter
name and documentation. Change runto as well, since the two are so
close (runto forwards all its arguments to gdb_breakpoint).
I wrote this for a downstrean GDB port, but thought it could be
useful upstream, eventually, even though not callers take advantage of
it yet.
Change-Id: I08175fd444d5a60df90fd9985e1b5dfd87c027cc
|
|
This commit updates the comments in the gdb/reggroups.{c,h} files.
Fill in some missing comments, correct a few comments that were not
clear, and where we had comments duplicated between .c and .h files,
update the .c to reference the .h.
No user visible changes after this commit.
|
|
Move 'struct reggroup' into the reggroups.h header. Remove the
reggroup_name and reggroup_type accessor functions, and just use the
name/type member functions within 'struct reggroup', update all uses
of these removed functions.
There should be no user visible changes after this commit.
|
|
Convert the 'struct reggroup' into a real class, with a constructor
and getter methods.
There should be no user visible changes after this commit.
|
|
Convert the 7 global, pre-defined, register groups const, and fix the
fall out (a minor tweak required in riscv-tdep.c).
There should be no user visible changes after this commit.
|
|
Convert the reggroup_new and reggroup_gdbarch_new functions to return
a 'const regggroup *', and fix up all the fallout.
There should be no user visible changes after this commit.
|
|
Add a new function gdbarch_reggroups that returns a reference to a
vector containing all the reggroups for an architecture.
Make use of this function throughout GDB instead of the existing
reggroup_next and reggroup_prev functions.
Finally, delete the reggroup_next and reggroup_prev functions.
Most of these changes are pretty straight forward, using range based
for loops instead of the old style look using reggroup_next. There
are two places where the changes are less straight forward.
In gdb/python/py-registers.c, the register group iterator needed to
change slightly. As the iterator is tightly coupled to the gdbarch, I
just fetch the register group vector from the gdbarch when needed, and
use an index counter to find the next item from the vector when
needed.
In gdb/tui/tui-regs.c the tui_reg_next and tui_reg_prev functions are
just wrappers around reggroup_next and reggroup_prev respectively.
I've just inlined the logic of the old functions into the tui
functions. As the tui function had its own special twist (wrap around
behaviour) I think this is OK.
There should be no user visible changes after this commit.
|
|
Replace manual linked list with a std::vector. This commit doesn't
change the reggroup_next and reggroup_prev API, but that will change
in a later commit.
This commit is focused on the minimal changes needed to manage the
reggroups using a std::vector, without changing the API exposed by the
reggroup.c file.
There should be no user visible changes after this commit.
|
|
There's a set of 7 default register groups. If we don't add any
gdbarch specific register groups during gdbarch initialisation, then
when we iterate over the register groups using reggroup_next and
reggroup_prev we will make use of these 7 default groups. See the use
of default_groups in gdb/reggroups.c for details on this.
However, if the gdbarch adds its own groups during gdbarch
initialisation, then these groups will be used in preference to the
default groups.
A problem arises though if the particular architecture makes use of
the target description mechanism. If the default target
description(s) (i.e. those internal to GDB that are used when the user
doesn't provide their own) don't mention any additional register
groups then the default register groups will be used.
But if the target description does mention additional groups then the
default groups are not used, and instead, the groups from the target
description are used.
The problem with this is that what usually happens is that the target
description will mention additional groups, e.g. groups for special
registers. Most architectures that use target descriptions work
around this by adding all (or most) of the default register groups in
all cases. See i386_add_reggroups, aarch64_add_reggroups,
riscv_add_reggroups, xtensa_add_reggroups, and others.
In this patch, my suggestion is that we should just add the default
register groups for every architecture, always. This change is in
gdb/reggroups.c.
All the remaining changes are me updating the various architectures to
not add the default groups themselves.
So, where will this change be visible to the user? I think the
following commands will possibly change:
* info registers / info all-registers:
The user can provide a register group to these commands. For example,
on csky, we previously never added the 'vector' group. Now, as a
default group, this will be available, but (presumably) will not
contain any registers. I don't think this is necessarily a bad
thing, there's something to be said for having some consistent
defaults available. There are other architectures that didn't add
all 7 of the defaults, which will now have gained additional groups.
* maint print reggroups
This prints the set of all available groups. As a maintenance
command I'm less concerned with the output changing here.
Obviously, for the architectures that didn't previously add all the
defaults, this list just got bigger.
* maint print register-groups
This prints all the registers, and the groups they are in. If the
defaults were not previously being added then a register (obviously)
can't appear in one of the default groups. Now the groups are
available then registers might be in more groups than previously.
However, this is again a maintenance command, so I'm less concerned
about this changing.
|
|
Start GDB like:
$ gdb -q executable
(gdb) start
(gdb) layout src
... tui windows are now displayed ...
(gdb) tui reg next
At this point the data (register) window should be displayed, but will
contain the message 'Register Values Unavailable', and at the console
you'll see the message "unknown register group 'next'".
The same happens with 'tui reg prev' (but the error message is
slightly different).
At this point you can continue to use 'tui reg next' and/or 'tui reg
prev' and you'll keep getting the error message.
The problem is that when the data (register) window is first
displayed, it's current register group is nullptr. As a consequence
tui_reg_next and tui_reg_prev (tui/tui-regs.c) will always just return
nullptr, which triggers an error in tui_reg_command.
In this commit I change tui_reg_next and tui_reg_prev so that they
instead return the first and last register group respectively if the
current register group is nullptr.
So, after this, using 'tui reg next' will (in the above case) show the
first register group, while 'tui reg prev' will display the last
register group.
|
|
While looking at the 'tui reg' command as part of another patch, I
spotted a theoretical bug.
The 'tui reg' command takes the name of a register group, but also
handles partial register group matches, though the partial match has to
be unique. The current command logic goes:
With the code as currently written, if a target description named a
register group either 'prev' or 'next' then GDB would see this as an
ambiguous register name, and refuse to switch groups.
Naming a register group 'prev' or 'next' seems pretty unlikely, but,
by adding a single else block we can prevent this problem.
Now, if there's a 'prev' or 'next' register group, the user will not
be able to select the group directly, the 'prev' and 'next' names will
always iterate through the available groups instead. But at least the
user could select their groups by iteration, rather than direct
selection.
|
|
Update reggroup_find to return a const reggroup *.
There are other function in gdb/reggroup.{c,h} files that could
benefit from returning const, these will be updated in later commits.
There should be no user visible changes after this commit.
|
|
Convert uses of 'struct reggroup *' in python/py-registers.c to be
'const'.
There should be no user visible changes after this commit.
|
|
Make uses of 'reggroup *' const throughout tui-regs.{c,h}.
There should be no user visible changes after this commit.
|
|
Change gdbarch_register_reggroup_p to take a 'const struct reggroup *'
argument. This requires a change to the gdb/gdbarch-components.py
script, regeneration of gdbarch.{c,h}, and then updates to all the
architectures that implement this method.
There should be no user visible changes after this commit.
|
|
This commit makes the 'struct reggroup *' argument const for the
following functions:
reggroup_next
reggroup_prev
reggroup_name
reggroup_type
There are other places that could benefit from const in the
reggroup.{c,h} files, but these will be changing in further commits.
There should be no user visible changes after this commit.
|
|
While working on a different patch, I triggered an assertion from the
initialize_current_architecture code, specifically from one of
the *_gdbarch_init functions in a *-tdep.c file. This exposes a
couple of issues with GDB.
This is easy enough to reproduce by adding 'gdb_assert (false)' into a
suitable function. For example, I added a line into i386_gdbarch_init
and can see the following issue.
I start GDB and immediately hit the assert, the output is as you'd
expect, except for the very last line:
$ ./gdb/gdb --data-directory ./gdb/data-directory/
../../src.dev-1/gdb/i386-tdep.c:8455: internal-error: i386_gdbarch_init: Assertion `false' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
... snip ...
---------------------
../../src.dev-1/gdb/i386-tdep.c:8455: internal-error: i386_gdbarch_init: Assertion `false' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) ../../src.dev-1/gdb/ser-event.c:212:16: runtime error: member access within null pointer of type 'struct serial'
Something goes wrong when we try to query the user. Note, I
configured GDB with --enable-ubsan, I suspect that without this the
above "error" would actually just be a crash.
The backtrace from ser-event.c:212 looks like this:
(gdb) bt 10
#0 serial_event_clear (event=0x675c020) at ../../src/gdb/ser-event.c:212
#1 0x0000000000769456 in invoke_async_signal_handlers () at ../../src/gdb/async-event.c:211
#2 0x000000000295049b in gdb_do_one_event () at ../../src/gdbsupport/event-loop.cc:194
#3 0x0000000001f015f8 in gdb_readline_wrapper (
prompt=0x67135c0 "../../src/gdb/i386-tdep.c:8455: internal-error: i386_gdbarch_init: Assertion `false' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugg"...)
at ../../src/gdb/top.c:1141
#4 0x0000000002118b64 in defaulted_query(const char *, char, typedef __va_list_tag __va_list_tag *) (
ctlstr=0x2e4eb68 "%s\nQuit this debugging session? ", defchar=0 '\000', args=0x7fffffffa6e0)
at ../../src/gdb/utils.c:934
#5 0x0000000002118f72 in query (ctlstr=0x2e4eb68 "%s\nQuit this debugging session? ")
at ../../src/gdb/utils.c:1026
#6 0x00000000021170f6 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_list_tag __va_list_tag *) (problem=0x6107bc0 <internal_error_problem>, file=0x2b976c8 "../../src/gdb/i386-tdep.c",
line=8455, fmt=0x2b96d7f "%s: Assertion `%s' failed.", ap=0x7fffffffa8e8) at ../../src/gdb/utils.c:417
#7 0x00000000021175a0 in internal_verror (file=0x2b976c8 "../../src/gdb/i386-tdep.c", line=8455,
fmt=0x2b96d7f "%s: Assertion `%s' failed.", ap=0x7fffffffa8e8) at ../../src/gdb/utils.c:485
#8 0x00000000029503b3 in internal_error (file=0x2b976c8 "../../src/gdb/i386-tdep.c", line=8455,
fmt=0x2b96d7f "%s: Assertion `%s' failed.") at ../../src/gdbsupport/errors.cc:55
#9 0x000000000122d5b6 in i386_gdbarch_init (info=..., arches=0x0) at ../../src/gdb/i386-tdep.c:8455
(More stack frames follow...)
It turns out that the problem is that the async event handler
mechanism has been invoked, but this has not yet been initialized.
If we look at gdb_init (in gdb/top.c) we can indeed see the call to
gdb_init_signals is after the call to initialize_current_architecture.
If I reorder the calls, moving gdb_init_signals earlier, then the
initial error is resolved, however, things are still broken. I now
see the same "Quit this debugging session? (y or n)" prompt, but when
I provide an answer and press return GDB immediately crashes.
So what's going on now? The next problem is that the call_readline
field within the current_ui structure is not initialized, and this
callback is invoked to process the reply I entered.
The problem is that call_readline is setup as a result of calling
set_top_level_interpreter, which is called from captured_main_1.
Unfortunately, set_top_level_interpreter is called after gdb_init is
called.
I wondered how to solve this problem for a while, however, I don't
know if there's an easy "just reorder some lines" solution here.
Looking through captured_main_1 there seems to be a bunch of
dependencies between printing various things, parsing config files,
and setting up the interpreter. I'm sure there is a solution hiding
in there somewhere.... I'm just not sure I want to spend any longer
looking for it.
So.
I propose a simpler solution, more of a hack/work-around. In utils.c
we already have a function filtered_printing_initialized, this is
checked in a few places within internal_vproblem. In some of these
cases the call gates whether or not GDB will query the user.
My proposal is to add a new readline_initialized function, which
checks if the current_ui has had readline initialized yet. If this is
not the case then we should not attempt to query the user.
After this change GDB prints the error message, the backtrace, and
then aborts (including dumping core). This actually seems pretty sane
as, if GDB has not yet made it through the initialization then it
doesn't make much sense to allow the user to say "no, I don't want to
quit the debug session" (I think).
|
|
Update binutils to recognize the NT_ARM_SYSTEM_CALL set that is dumped by
Linux to core files.
|
|
bfd * coff-i386.c (in_reloc_p): Add R_SECTION.
(howto_table): Add R_SECTION.
(coff_pe_i386_relocation_section): Add support for R_SECTION.
(coff_i386_reloc_type_lookup): Add support for
BFD_RELOC_16_SECCIDX.
* coff-x86_64.c (in_reloc_p): Add R_SECTION.
(howto_table): Add R_SECTION.
(coff_pe_amd64_relocation_section): Add support for R_SECTION.
(coff_amd64_reloc_type_lookup): Add support for
BFD_RELOC_16_SECCIDX.
* reloc.c: Add BFD_RELOC_16_SECIDX.
* bfd-in2.h: Regenerate.
* libbfd.h: Regenerate.
gas * config/tc-i386.c (pe_directive_secidx): New function.
(md_pseudo_table): Add support for secidx.
(x86_cons_fix_new): Likewise.
(tc_gen_reloc): Likewise.
* expr.c (op_rank): Add O_secidx.
* expr.h (operatorT): Likewise.
* symbols.c (resolve_symbol_value): Add support for O_secidx.
* testsuite/gas/i386/secidx.s: New test source file.
* testsuite/gas/i386/secidx.d: New test driver file.
* testsuite/gas/i386/i386.exp: Run new test.
include * coff/i386.h: Define R_SECTION.
* coff/x86_64.h: Likewise.
ld * testsuite/ld-pe/secidx1.s: New test source file.
* testsuite/ld-pe/secidx2.s: New test source file.
* testsuite/ld-pe/secidx.d: New test driver file.
* testsuite/ld-pe/secidx_64.d: New test driver file.
* testsuite/ld-pe/pe.exp: Add new tests.
|
|
To help tools like addr2line looking up function names, in particular
when dealing with e.g. PE/COFF binaries (linked from ELF objects), where
there's no ELF symbol table to fall back to, emit minimalistic
information for functions marked as such and having their size
specified.
Notes regarding the restriction to (pure) ELF:
- I realize this is a layering violation; I don't see how to deal with
that in a better way.
- S_GET_SIZE(), when OBJ_MAYBE_ELF is defined, looks wrong: Unlike
S_SET_SIZE() it does not check whether the hook is NULL.
- symbol_get_obj(), when OBJ_MAYBE_ELF is defined, looks unusable, as
its return type can only ever be one object format's type (and this
may then not be ELF's).
The new testcases are limited to x86 because I wanted to include the
case where function size can't be determined yet at the time Dwarf2 info
is generated. As .nops gains support by further targets, they could also
be added here then (with, as necessary, expecations suitably relaxed to
cover for insn size differences).
|
|
Just like insns encoded the more conventional way these should have line
number info associated with them.
|
|
Just like insns encoded the more conventional way these should have line
number info associated with them.
|
|
Since no such test looks to exist, derive one from insn.s.
|
|
So far z16 was identified as arch14. After the machine has been
announced we can now add the real name.
gas/ChangeLog:
* config/tc-s390.c (s390_parse_cpu): Add z16 as alternate CPU
name.
* doc/as.texi: Add z16 and arch14 to CPU string list.
* doc/c-s390.texi: Add z16 to CPU string list.
opcodes/ChangeLog:
* s390-mkopc.c (main): Enable z16 as CPU string in the opcode
table.
|
|
|
|
$ objdump -d outputs/gdb.base/varargs/varargs
00000001200012e8 <find_max_float_real>:
...
1200013b8: c7c10000 lwc1 $f1,0(s8)
1200013bc: c7c00004 lwc1 $f0,4(s8)
1200013c0: 46000886 mov.s $f2,$f1
1200013c4: 46000046 mov.s $f1,$f0
1200013c8: 46001006 mov.s $f0,$f2
1200013cc: 46000886 mov.s $f2,$f1
1200013d0: 03c0e825 move sp,s8
1200013d4: dfbe0038 ld s8,56(sp)
1200013d8: 67bd0080 daddiu sp,sp,128
1200013dc: 03e00008 jr ra
1200013e0: 00000000 nop
From the above disassembly, we can see that when the return value of the
function is a complex type and len <= 2 * MIPS64_REGSIZE, the return value
will be passed through $f0 and $f2, so fix the corresponding processing
in mips_n32n64_return_value().
$ make check RUNTESTFLAGS='GDB=../gdb gdb.base/varargs.exp --outdir=test'
Before applying the patch:
FAIL: gdb.base/varargs.exp: print find_max_float_real(4, fc1, fc2, fc3, fc4)
FAIL: gdb.base/varargs.exp: print find_max_double_real(4, dc1, dc2, dc3, dc4)
# of expected passes 9
# of unexpected failures 2
After applying the patch:
# of expected passes 11
This also fixes:
FAIL: gdb.base/callfuncs.exp: call inferior func with struct - returns float _Complex
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>
|
|
This changes jit.c to use new and delete, rather than XCNEW. This
simplifies the code a little. This was useful for another patch I'm
working on, and I thought it would make sense to send it separately.
Regression tested on x86-64 Fedora 34.
|
|
Bug 28980 shows that trying to value_copy an entirely optimized out
value causes an internal error. The original bug report involves MI and
some Python pretty printer, and is quite difficult to reproduce, but
another easy way to reproduce (that is believed to be equivalent) was
proposed:
$ ./gdb -q -nx --data-directory=data-directory -ex "py print(gdb.Value(gdb.Value(5).type.optimized_out()))"
/home/smarchi/src/binutils-gdb/gdb/value.c:1731: internal-error: value_copy: Assertion `arg->contents != nullptr' failed.
This is caused by 5f8ab46bc691 ("gdb: constify parameter of
value_copy"). It added an assertion that the contents buffer is
allocated if the value is not lazy:
if (!value_lazy (val))
{
gdb_assert (arg->contents != nullptr);
This was based on the comment on value::contents, which suggest that
this is the case:
/* Actual contents of the value. Target byte-order. NULL or not
valid if lazy is nonzero. */
gdb::unique_xmalloc_ptr<gdb_byte> contents;
However, it turns out that it can also be nullptr also if the value is
entirely optimized out, for example on exit of
allocate_optimized_out_value. That function creates a lazy value, marks
the entire value as optimized out, and then clears the lazy flag. But
contents remains nullptr.
This wasn't a problem for value_copy before, because it was calling
value_contents_all_raw on the input value, which caused contents to be
allocated before doing the copy. This means that the input value to
value_copy did not have its contents allocated on entry, but had it
allocated on exit. The result value had it allocated on exit. And that
we copied bytes for an entirely optimized out value (i.e. meaningless
bytes).
From here I see two choices:
1. respect the documented invariant that contents is nullptr only and
only if the value is lazy, which means making
allocate_optimized_out_value allocate contents
2. extend the cases where contents can be nullptr to also include
values that are entirely optimized out (note that you could still
have some entirely optimized out values that do have contents
allocated, it depends on how they were created) and adjust
value_copy accordingly
Choice #1 is safe, but less efficient: it's not very useful to allocate
a buffer for an entirely optimized out value. It's even a bit less
efficient than what we had initially, because values coming out of
allocate_optimized_out_value would now always get their contents
allocated.
Choice #2 would be more efficient than what we had before: giving an
optimized out value without allocated contents to value_copy would
result in an optimized out value without allocated contents (and the
input value would still be without allocated contents on exit). But
it's more risky, since it's difficult to ensure that all users of the
contents (through the various_contents* accessors) are all fine with
that new invariant.
In this patch, I opt for choice #2, since I think it is a better
direction than choice #1. #1 would be a pessimization, and if we go
this way, I doubt that it will ever be revisited, it will just stay that
way forever.
Add a selftest to test this. I initially started to write it as a
Python test (since the reproducer is in Python), but a selftest is more
straightforward.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28980
Change-Id: I6e2f5c0ea804fafa041fcc4345d47064b5900ed7
|
|
This is the last of the correctness fixes I've been carrying around for the
v850.
Like the other recent fixes, this is another case where we haven't been as
careful as we should WRT host vs target types. For the divq instruction
both operands are 32 bit types. Yet in the simulator code we convert them
from unsigned int to signed long by assignment. So 0xfffffffb (aka -5)
turns into 4294967291 and naturally that changes the result of our division.
The fix is simple, insert a cast to int32_t to force interpretation as a
signed value.
Testcase for the simulator is included. It has a trivial dependency on the
bins patch.
|
|
I've been carrying this for a few years. One test in the GCC testsuite is
failing due to a bug in the handling of the v850e3v5 instruction "bins".
When the "bins" instruction specifies a 32bit bitfield size, the simulator
exhibits undefined behavior by trying to shift a 32 bit quantity by 32 bits.
In the case of a 32 bit shift, we know what the resultant mask should be. So
we can just set it.
That seemed better than using 1UL for the constant (on a 32bit host unsigned
long might still just be 32 bits) or needlessly forcing everything to
long long types.
Thankfully the case where this shows up is only bins <src>, 0, 32, <dest>
which would normally be encoded as a simple move.
* testsuite/v850/allinsns.exp: Add v850e3v5.
* testsuite/v850/bins.cgs: New test.
* v850/simops.c (v850_bins): Avoid undefined behavior on left shift.
|
|
Implement the "init" method of struct tramp_frame to prepend tramp
frame unwinder for signal on LoongArch.
With this patch, the following failed testcases can be fixed:
FAIL: gdb.base/annota1.exp: backtrace @ signal handler (timeout)
FAIL: gdb.base/annota3.exp: backtrace @ signal handler (pattern 2)
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
Since this commit:
commit 8322445e0584be846f5873b9aab257dc9fbda05d
Date: Tue Jun 21 01:11:45 2016 +0100
Introduce interpreter factories
Interpreters should be registered with GDB, not by calling interp_add,
but with a call to interp_factory_register. I've checked the insight
source, and it too has moved over to using interp_factory_register.
In this commit I make interp_add static within interps.c.
There should be no user visible change after this commit.
|
