The header shuffling in here broke the workaround for gnulib defining
"open". Move it back before the sim-specific includes to fix. This
is because the callback struct in the headers has an "open" member and
this file tries to call that.
In a cross toolchain for nios2-elf target and x86_64-w64-mingw32 host
using binutils 2.37, we observed a failure that didn't show up on
x86_64-linux-gnu host: testcase pr25490-5.s was failing with
C:\path\to\nios2-elf-ld.exe: looping in map_segments
FAIL: __patchable_function_entries section 5
* ldelfgen.c (compare_link_order): Don't use section id in
sorting. Keep original ordering instead. Update comments.
Using an unsigned int cast (to 32 bits) on a pointer difference (of
possibly 64 bits) is wrong. Even though it will work on all real
object files, the fuzzers will eventually find this hole.
PR 28687
* dwarf1.c (parse_die): Cast pointer difference to size_t.
Catch another possible pointer overflow.
PR28691 is a fuzzing PR that triggers a non-problem of "output changes
per run" with PIEs and/or different compilers. I've closed similar
PRs before as wontfix, but I guess there will be no end of this type
of PR. The trigger is an attribute that usually takes one of the
offset/constant reference DW_FORMs being given an indexed string
DW_FORM. The bfd reader doesn't support indexed strings and returns
an error string instead. The address of the string varies with PIE
runs and/or compiler, and we allow that address to appear in output.
Fix this by validating integer attribute forms, as we do for string
form attributes.
PR 28691
* dwarf2.c (is_str_attr): Rename to..
(is_str_form): ..this. Change param type. Update calls.
(is_int_form): New function.
(read_attribute_value): Handle DW_FORM_addrx2.
(find_abstract_instance): Validate form when using attr.u.val.
(scan_unit_for_symbols, parse_comp_unit): Likewise.
Add the --enable-threading configure option so multithreading can be disabled
at configure time. This is useful for statically-linked builds of
GDB/GDBserver, since the thread library doesn't play well with that setup.
If you try to run a statically-linked GDB built with threading, it will crash
when setting up the number of worker threads.
This new option is also convenient when debugging GDB in a system with lots of
threads, where the thread discovery code in GDB will emit too many messages,
like so:
[New Thread 0xfffff74d3a50 (LWP 2625599)]
If you have X threads, that message will be repeated X times.
The default for --enable-threading is "yes".
gas/config/tc-loongarch.c: In function ‘assember_macro_helper’:
gas/config/tc-loongarch.c:915:28: error: right shift count >= width of type [-Werror=shift-count-overflow]
915 | hi32 = insn->args[1] >> 32;
| ^~
One possible fix is to make offsetT a 64-bit type for loongarch32.
This also makes bfd/targmatch.h (generated from bfd/config.bfd)
consistent since the loongarch32 match is inside #ifdef BFD64.
* config.bfd (loongarch32-*): Set want64.
gas/config/tc-loongarch.c: In function ‘loongarch_args_parser_can_match_arg_helper’:
gas/config/tc-loongarch.c:661:13: error: cast from pointer to integer of different size [-Werror=pointer
-to-int-cast]
661 | imm = (offsetT) str_hash_find (r_htab, arg);
| ^
Cast it to the correct size int, relying on normal integer promotions
if offsetT is larger than a pointer.
* config/tc-loongarch.c (loongarch_args_parser_can_match_arg_helper):
Cast return from str_hash_find to intptr_t, not offsetT.
This test was failing here and on another similar symbol:
[ 4](sec 1)(fl 0x00)(ty 0)(scl 143) (nx 0) 0x05d1745d11745d21 .bs
where correct output is
[ 4](sec 1)(fl 0x00)(ty 0)(scl 143) (nx 0) 0x000000000000000a .bs
The problem is caused by a 32-bit host pointer being sign-extended
when stored into a 64-bit bfd_vma, and then that value not being
trimmed back to 32 bits when used. The following belt-and-braces
patch fixes both the store and subsequent reads.
* coffcode.h (coff_slurp_symbol_table): Do not sign extend
when storing a host pointer to syment.n_value.
* coffgen.c (coff_get_symbol_info): Cast syment.n_value to a
bfd_hostptr_t before using in arithmetic.
(coff_print_symbol): Likewise.
If we modify tracepoint.cc to try to use a too long unix socket name,
for example by modifying SOCK_DIR to be:
#define SOCK_DIR "/tmp/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut"
... trying to start an application with libinproctrace.so loaded
crashes:
$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6:./libinproctrace.so /bin/ls
/home/smarchi/src/binutils-gdb/gdbserver/../gdbsupport/common-utils.cc:69: A problem internal to GDBserver in-process agent has been detected.
xsnprintf: Assertion `ret < size' failed.
Looking at the rest of the socket initialization code, the intent seems
to be that if something goes wrong, we warn but let the program
execute. So crashing on this failed assertions seems against the intent.
Commit 6cebaf6e1a ("use xsnprintf instead of snprintf.") changed this
code to use xsnprintf instead of snprintf, introducing this assertion.
Before that, snprintf would return a value bigger that UNIX_PATH_MAX and
the "if" after would catch it and emit a warning, which is exactly what
we want. That change was done because LynxOS didn't have snprintf.
Since LynxOS isn't supported anymore, we can simply revert to use
snprintf there.
With this patch, we get a warning (printed by the caller of
gdb_agent_socket_init), but the program keeps executing:
$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6:./libinproctrace.so /bin/ls
ipa: could not create sync socket
...
Change-Id: I78bca52d5dc3145335abeae45a42052701e3f5dd
When building gdb with on AArch64 with g++ 11.1.0 (and some preceding
versions too), -O2 and -fsanitize=address, I get this error.
CXX tracepoint-ipa.o
cc1plus: warning: command-line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++
In file included from /usr/include/string.h:519,
from ../gnulib/import/string.h:41,
from /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/common-defs.h:95,
from /home/simark/src/binutils-gdb/gdbserver/server.h:22,
from /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:19:
In function ‘char* strncpy(char*, const char*, size_t)’,
inlined from ‘int init_named_socket(const char*)’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:6902:11,
inlined from ‘int gdb_agent_socket_init()’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:6953:26,
inlined from ‘void* gdb_agent_helper_thread(void*)’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:7204:41:
/usr/include/bits/string_fortified.h:95:34: error: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ output may be truncated copying 107 bytes from a string of length 107 [-Werror=stringop-truncation]
95 | return __builtin___strncpy_chk (__dest, __src, __len,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
96 | __glibc_objsize (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~
Note that _FORTIFY_SOURCE changes the message a bit, but I get a similar
error if I use -D_FORTIFY_SOURCE=0.
I am pretty sure it's spurious and might be related to this GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780
From what I can see, we are copying from a static 108 bytes long buffer
(the global array agent_socket_name) to a 108 bytes long array,
sockaddr_un::sun_path. I don't see anything wrong.
Still, it would make things easier if we didn't see this error. Change
the code to check that the source string length is smaller than the
destination buffer (including space for the NULL byte) and use strcpy.
For anybody who would like to try to reproduce, the full command line
is:
g++ -I. -I/home/simark/src/binutils-gdb/gdbserver -I/home/simark/src/binutils-gdb/gdbserver/../gdb/regformats -I/home/simark/src/binutils-gdb/gdbserver/.. -I/home/simark/src/binutils-gdb/gdbserver/../include -I/home/simark/src/binutils-gdb/gdbserver/../gdb -I/home/simark/src/binutils-gdb/gdbserver/../gnulib/import -I../gnulib/import -I/home/simark/src/binutils-gdb/gdbserver/.. -I.. -pthread -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor -Wredundant-move -Wmissing-declarations -Wmissing-prototypes -Wstrict-null-sentinel -Wformat -Wformat-nonliteral -Werror -DGDBSERVER -DCONFIG_UST_GDB_INTEGRATION -Drpl_strerror_r=strerror_r -Drpl_free=free -fPIC -DIN_PROCESS_AGENT -fvisibility=hidden -g3 -O2 -fsanitize=address -c -o tracepoint-ipa.o -MT tracepoint-ipa.o -MMD -MP -MF ./.deps/tracepoint-ipa.Tpo /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc
Change-Id: I18e86c0487feead7e7677e69398405e7057cf464
Clang 13 and 14 produce some -Wunused-but-set-{variable,parameter} for
situations where gcc doesn't. In particular, when a variable is set and
then used in a way to update its own value. For example, if `i` is only
used in this way:
int i = 2;
i++;
i = i + 1;
gcc won't warn, but clang will.
Fix all such errors found in an --enable-targets=all build. It would be
important for somebody who knows what they're doing to just make sure
that these variables can indeed be deleted, and that there a no cases
where it's a bug, and the variable should actually be used.
The first instance of this error fix by this patch is:
CC elf32-score.lo
/home/simark/src/binutils-gdb/bfd/elf32-score.c:450:11: error: variable 'relocation' set but not used [-Werror,-Wunused-but-set-variable]
bfd_vma relocation;
^
Change-Id: I2f233ce20352645cf388aff3dfa08a651d21a6b6
Just give this class a new name, more inline with the name of the
sub-classes. I've also updated mi_cmd_up to mi_command_up in
mi-cmds.c inline with this new naming scheme.
There should be no user visible changes after this commit.
This commit changes the infrastructure in mi-cmds.{c,h} to add new
sub-classes for the different types of MI command. Instances of these
sub-classes are then created and added into mi_cmd_table.
The existing mi_cmd class becomes the abstract base class, this has an
invoke method and takes care of the suppress notifications handling,
before calling a do_invoke virtual method which is implemented by all
of the sub-classes.
There's currently two different sub-classes, one of pure MI commands,
and a second for MI commands that delegate to CLI commands.
There should be no user visible changes after this commit.
Change an argument of mi_execute_cli_command from int to bool. Update
the callers to take this into account. Within mi_execute_cli_command,
update a comparison of a pointer to 0 with a comparison to nullptr,
and add an assert, if we are not using the argument string then the
string should be nullptr. Also removed a cryptic 'gdb_????' comment,
which isn't really helpful.
There should be no user visible changes after this commit.
This changes the hashmap used in mi-cmds.c from a custom structure to
std::map. Not only is replacing a custom container with a standard
one an improvement, but using std::map will make it easier to
dynamically add commands; which is something that is planned for a
later series, where we will allow MI commands to be implemented in
Python.
There should be no user visible changes after this commit.
Lets give this function a more descriptive name. I've also improved
the comments in the header and source files.
There should be no user visible changes after this commit.
There are two linker scripts, code-model-01.ld and code-model-02.ld,
which are corresponding to the two different memory layouts,
* code-model-01.ld: the text section is in the 32-bit address range, but
the data section is far away from the text section, which means the data
section is over the 32-bit address range.
* code-model-02.ld: the text section is over the 32-bit address range, but
the data section is placed nearly zero address.
We use the two linker scripts, to test the current medlow and medany behaviors
of GNU ld, including the weak symbol references and the relaxations behaviors.
Besides, these testcases also show the limits of the current medlow and medany
code models, that is - we may get the truncated to fit errors when linking
with the above two linker scripts.
ld/
* testsuite/ld-riscv-elf/code-model-01.ld: New testcases to test the
behaviors of the current medlow and medany code models.
* testsuite/ld-riscv-elf/code-model-02.ld: Likewise.
* testsuite/ld-riscv-elf/code-model-medany-01.d: Likewise.
* testsuite/ld-riscv-elf/code-model-medany-02.d: Likewise.
* testsuite/ld-riscv-elf/code-model-medany-weakref-01.d: Likewise.
* testsuite/ld-riscv-elf/code-model-medany-weakref-02.d: Likewise.
* testsuite/ld-riscv-elf/code-model-medlow-01.d: Likewise.
* testsuite/ld-riscv-elf/code-model-medlow-02.d: Likewise.
* testsuite/ld-riscv-elf/code-model-medlow-weakref-01.d: Likewise.
* testsuite/ld-riscv-elf/code-model-medlow-weakref-02.d: Likewise.
* testsuite/ld-riscv-elf/code-model-relax-medany-01.d: Likewise.
* testsuite/ld-riscv-elf/code-model-relax-medany-02.d: Likewise.
* testsuite/ld-riscv-elf/code-model-relax-medany-weakref-01.d: Likewise.
* testsuite/ld-riscv-elf/code-model-relax-medany-weakref-02.d: Likewise.
* testsuite/ld-riscv-elf/code-model-relax-medlow-01.d: Likewise.
* testsuite/ld-riscv-elf/code-model-relax-medlow-02.d: Likewise.
* testsuite/ld-riscv-elf/code-model-relax-medlow-weakref-01.d: Likewise.
* testsuite/ld-riscv-elf/code-model-relax-medlow-weakref-02.d: Likewise.
* testsuite/ld-riscv-elf/code-model.s: Likewise.
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
Powerpc is not reporting the
Catchpoint 1 (returned from syscall execve), ....
as expected. The issue appears to be with the kernel not returning the
expected result. This patch marks the test failure as an xfail.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28623
While working on a Python script, which was interacting with a remote
target, I noticed some weird slowness in GDB. In my program I had a
structure something like this:
struct foo_t
{
int array[5];
};
struct foo_t global_foo;
Then in the Python script I was fetching a complete copy of global
foo, like:
val = gdb.parse_and_eval('global_foo')
val.fetch_lazy()
Then I would work with items in foo_t.array, like:
print(val['array'][1])
I called the fetch_lazy method specifically because I knew I was going
to end up accessing almost all of the contents of val, and so I wanted
GDB to do a single remote protocol call to fetch all the contents in
one go, rather than trying to do lazy fetches for a couple of bytes at
a time.
What I observed was that, after the fetch_lazy call, GDB does,
correctly, fetch the entire contents of global_foo, including all of
the contents of array, however, when I access val.array[1], GDB still
goes and fetches the value of this element from the remote target.
What's going on is that in valarith.c, in value_subscript, for C like
languages, we always end up treating the array value as a pointer, and
then doing value_ptradd, and value_ind, the second of these calls
always returns a lazy value.
My guess is that this approach allows us to handle indexing off the
end of an array, when working with zero element arrays, or when
indexing a raw pointer as an array. And, I agree, that in these
cases, where, even when the original value is non-lazy, we still will
not have the content of the array loaded, we should be using the
value_ind approach.
However, for cases where we do have the array contents loaded, and we
do know the bounds of the array, I think we should be using
value_subscripted_rvalue, which is what we use for non C like
languages.
One problem I did run into, exposed by gdb.base/charset.exp, was that
value_subscripted_rvalue stripped typedefs from the element type of
the array, which means the value returned will not have the same type
as an element of the array, but would be the raw, non-typedefed,
type. In charset.exp we got back an 'int' instead of a
'wchar_t' (which is a typedef of 'int'), and this impacts how we print
the value. Removing typedefs from the resulting value just seems
wrong, so I got rid of that, and I don't see any test regressions.
With this change in place, my original Python script is now doing no
additional memory accesses, and its performance increases about 10x!
This commit updates uses of 'loc' and 'loc_kind' to 'm_loc' and
'm_loc_kind' respectively, in gdb-gdb.py.in, which is required after
this commit:
commit cd3f655cc7
Date: Thu Sep 30 22:38:29 2021 -0400
gdb: add accessors for field (and call site) location
I have also incorporated this change:
https://sourceware.org/pipermail/gdb-patches/2021-September/182171.html
Which means we print 'm_name' instead of 'name' when displaying the
'm_name' member variable.
Finally, I have also added support for the new TYPE_SPECIFIC_INT
fields, which were added with this commit:
commit 20a5fcbd5b
Date: Wed Sep 23 09:39:24 2020 -0600
Handle bit offset and bit size in base types
I updated the gdb.gdb/python-helper.exp test to cover all of these
changes.
Replace the direct assignments to current_thread with
switch_to_thread. Use scoped_restore_current_thread when appropriate.
There is one instance remaining in linux-low.cc's wait_for_sigstop.
This will be handled in a separate patch.
Regression-tested on X86-64 Linux using the native-gdbserver and
native-extended-gdbserver board files.
Introduce a class for restoring the current thread and a function to
switch to the given thread. This is a preparation for a refactoring
that aims to remove direct assignments to 'current_thread'.
While working on a later patch that required me to understand how GDB
starts up inferiors, I was confused by the
target_ops::post_startup_inferior method.
The post_startup_inferior target function is only called from
inf_ptrace_target::create_inferior.
Part of the target class hierarchy looks like this:
inf_child_target
|
'-- inf_ptrace_target
|
|-- linux_nat_target
|
|-- fbsd_nat_target
|
|-- nbsd_nat_target
|
|-- obsd_nat_target
|
'-- rs6000_nat_target
Every sub-class of inf_ptrace_target, except rs6000_nat_target,
implements ::post_startup_inferior. The rs6000_nat_target picks up
the implementation of ::post_startup_inferior not from
inf_ptrace_target, but from inf_child_target.
No descendent of inf_child_target, outside the inf_ptrace_target
sub-tree, implements ::post_startup_inferior, which isn't really
surprising, as they would never see the method called (remember, the
method is only called from inf_ptrace_target::create_inferior).
What I find confusing is the role inf_child_target plays in
implementing, what is really a helper function for just one of its
descendents.
In this commit I propose that we formally make ::post_startup_inferior
a helper function of inf_ptrace_target. To do this I will remove the
::post_startup_inferior from the target_ops API, and instead make this
a protected, pure virtual function on inf_ptrace_target.
I'll remove the empty implementation of ::post_startup_inferior from
the inf_child_target class, and add a new empty implementation to the
rs6000_nat_target class.
All the other descendents of inf_ptrace_target already provide an
implementation of this method and so don't need to change beyond
making the method protected within their class declarations.
To me, this makes much more sense now. The helper function, which is
only called from within the inf_ptrace_target class, is now a part of
the inf_ptrace_target class.
The only way in which this change is visible to a user is if the user
turns on 'set debug target 1'. With this debug flag on, prior to this
patch the user would see something like:
-> native->post_startup_inferior (...)
<- native->post_startup_inferior (2588939)
After this patch these lines are no longer present, as the
post_startup_inferior is no longer a top level target method. For me,
this is an acceptable change.
While working on another patch I had reason to look at
mips-netbsd-nat.c, and noticed that the class mips_nbsd_nat_target
inherits directly from inf_ptrace_target.
This is a little strange as alpha_bsd_nat_target,
arm_netbsd_nat_target, hppa_nbsd_nat_target, m68k_bsd_nat_target,
ppc_nbsd_nat_target, sh_nbsd_nat_target, and vax_bsd_nat_target all
inherit from nbsd_nat_target.
Originally, in this commit:
commit f6ac5f3d63
Date: Thu May 3 00:37:22 2018 +0100
Convert struct target_ops to C++
When the target tree was converted to C++, all of the above classes
inherited from inf_ptrace_target except for hppa_nbsd_nat_target,
which was the only class that originally inherited from
nbsd_nat_target.
Later on all the remaining targets (except mips) were converted to
inherit from nbsd_nat_target, these are the commits:
commit 4fed520be2
Date: Sat Mar 14 16:05:24 2020 +0100
Inherit alpha_netbsd_nat_target from nbsd_nat_target
commit 6018d381a0
Date: Sat Mar 14 14:50:51 2020 +0100
Inherit arm_netbsd_nat_target from nbsd_nat_target
commit 01a801176e
Date: Sat Mar 14 16:54:42 2020 +0100
Inherit m68k_bsd_nat_target from nbsd_nat_target
commit 9faa006d11
Date: Thu Mar 19 14:52:57 2020 +0100
Inherit ppc_nbsd_nat_target from nbsd_nat_target
commit 9809762324
Date: Tue Mar 17 15:07:39 2020 +0100
Inherit sh_nbsd_nat_target from nbsd_nat_target
commit d5be5fa420
Date: Sat Mar 14 13:21:58 2020 +0100
Inherit vax_bsd_nat_target from nbsd_nat_target
I could only find mailing list threads for ppc and sh in the archive ,
and unfortunately, none of the commits has any real detail that might
explain why mips was missed out, the only extra context I could find
was this message:
https://sourceware.org/pipermail/gdb-patches/2020-March/166853.html
Which says that "proper" OS support is going to be added to
nbsd_nat_target, hence the need to inherit from that class.
My guess is that leaving mips_nbsd_nat_target unchanged was an
oversight, so, in this commit, I propose changing mips_nbsd_nat_target
to inherit from nbsd_nat_target just like all the other nbsd targets.
My motivation for this patch relates to the post_startup_inferior
target method. In a future commit I want to change how this method is
handled. Currently the mips_nbsd_nat_target will pick up the empty
implementation of inf_child_target::post_startup_inferior rather than
the version in netbsd-nat.c. This feels like a bug to me, as surely,
enabling of proc events is something that would need to be done for
all netbsd targets, regardless of architecture.
In my future patch I have a choice then, either (a) add a new, empty
implementation of post_startup_inferior to mips_nbsd_nat_target,
or (b) this commit, have mips_nbsd_nat_target inherit from
nbsd_nat_target. Option (b) seems like the right way to go, hence,
this commit.
I've done absolutely no testing for this change, not even building it,
as that would require at least an environment in which I can x-build
mips-netbsd applications, which I have no idea how to set up.
While testing another patch I was trying to build different
configurations of GDB, and, during one test build I ran into a
problem, I configured with `--enable-targets=all
--host=i686-w64-mingw32` and saw this error while linking GDB:
.../i686-w64-mingw32/bin/ld: mips-tdep.o: in function `mips_gdbarch_init':
.../src/gdb/mips-tdep.c:8730: undefined reference to `disassembler_options_mips'
.../i686-w64-mingw32/bin/ld: riscv-tdep.o: in function `riscv_gdbarch_init':
.../src/gdb/riscv-tdep.c:3851: undefined reference to `disassembler_options_riscv'
So the `disassembler_options_mips` and `disassembler_options_riscv`
symbols are missing.
This turns out to be because mips-dis.c and riscv-dis.c, in which
these symbols are defined, are in the TARGET64_LIBOPCODES_CFILES list
in opcodes/Makefile.am, these files are only built when we are
building with a 64-bit bfd.
If we look further, into bfd/Makefile.am, we can see that all the
files matching elf*-riscv.lo are in the BFD64_BACKENDS list, as are
the elf*-mips.lo files, and (I know because I tried), the two
disassemblers do, not surprisingly, depend on features supplied from
libbfd.
So, though we can build most of GDB just fine for riscv and mips with
a 32-bit bfd, if I understand correctly, the final GDB
executable (assuming we could get it to link) would not understand
these architectures at the bfd level, nor would there be any
disassembler available. This sounds like a pretty useless GDB to me.
So, in this commit, I move the riscv and mips targets into GDB's list
of targets that require a 64-bit bfd. After this I can build GDB just
fine with the configure options given above.
This was discussed on the mailing list in a couple of threads:
https://sourceware.org/pipermail/gdb-patches/2021-December/184365.htmlhttps://sourceware.org/pipermail/binutils/2021-November/118498.html
and it is agreed, that it is unfortunate that the 32-bit riscv and
32-bit mips targets require a 64-bit bfd. If in the future this
situation ever changes then it would be expected that some (or all) of
this patch would be reverted. Until then though, this patch allows
GDB to build when configured with --enable-targets=all, and when using
a 32-bit libbfd.
I found some uses of xfree in the path substitution code in source.c.
C++-ifying struct substitute_path_rule both simplifies the code and
removes manual memory management.
Regression tested on x86-64 Fedora 34.
On Fedora 35,
$ readelf -d /usr/bin/npc
caused readelf to run out of stack since load_separate_debug_info
returned the input main file as the separate debug info:
(gdb) bt
#0 load_separate_debug_info (
main_filename=main_filename@entry=0x510f50 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo",
xlink=xlink@entry=0x4e5180 <debug_displays+4480>,
parse_func=parse_func@entry=0x431550 <parse_gnu_debuglink>,
check_func=check_func@entry=0x432ae0 <check_gnu_debuglink>,
func_data=func_data@entry=0x7fffffffdb60, file=file@entry=0x51d430)
at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11057
#1 0x000000000043328d in check_for_and_load_links (file=0x51d430,
filename=0x510f50 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo")
at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11381
#2 0x00000000004332ae in check_for_and_load_links (file=0x51b070,
filename=0x518dd0 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo")
Return NULL if the separate debug info is the same as the input main
file to avoid infinite recursion.
PR binutils/28679
* dwarf.c (load_separate_debug_info): Don't return the input
main file.
This reverts a 1995 fix to handle bogus object files. Presumably such
object files have long gone.
* elf.c (bfd_section_from_shdr): Remove old hack for Oracle
libraries.
The comment on top of gdb/testsuite/boards/remote-stdio-gdbserver.exp says
that user can specify path to gdbserver on remote system by setting
GDBSERVER variable. However, this variable was ignored and /usr/bin/gdbserver
was used unconditionally.
This commit updates the code to respect GDBSERVER if set and fall back to
/usr/bin/gdbserver if not.
This reverts commit fe72c32765.
It turns out it was wrong, libinproctrace.so does build its own
gdbsupport/tdesc.cc. This broke the build:
make[1]: Entering directory '/home/simark/build/binutils-gdb-one-target/gdbserver'
CXXLD libinproctrace.so
/usr/bin/ld: gdbsupport/tdesc-ipa.o: in function `print_xml_feature::visit_pre(target_desc const*)':
/home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:407: undefined reference to `tdesc_architecture_name(target_desc const*)'
/usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:408: undefined reference to `tdesc_architecture_name(target_desc const*)'
/usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:411: undefined reference to `tdesc_osabi_name(target_desc const*)'
/usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:416: undefined reference to `tdesc_compatible_info_list(target_desc const*)'
/usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:418: undefined reference to `tdesc_compatible_info_arch_name(std::unique_ptr<tdesc_compatible_info, std::default_delete<tdesc_compatible_info> > const&)'
Not returning an error indication here leaves the attribute
uninitialised, which then leads to intemperate behaviour.
PR 28674
* dwarf2.c (read_attribute_value): Return NULL on trying to read
past end of attributes.
binutils-all/strip-13 and binutils-all/strip-14 tests create
SHT_REL/SHT_RELA sections by hand. These don't have sh_link set to
the .symtab section as they should, leading to readelf warnings if you
happen to be looking at the object files.
* elf.c (assign_section_numbers): Formatting. Set sh_link for
reloc sections created as normal sections in relocatable
objects.
I suppose this code was copied from GDBserver and this ifndef was left
there. As far as I know, IN_PROCESS_AGENT will never be defined when
building this file, so we can remove this.
Change-Id: I84fc408e330b3a29106df830a09342861cadbaf6
Fix this, seen when building with clang 14:
CXX microblaze-tdep.o
/home/simark/src/binutils-gdb/gdb/microblaze-tdep.c:207:7: error: variable 'flags' set but not used [-Werror,-Wunused-but-set-variable]
int flags = 0;
^
Change-Id: I59f726ed33e924912748bc475b6fd9a9394fc0d0
Fix these, seen when building with clang 14:
CXX csky-tdep.o
/home/simark/src/binutils-gdb/gdb/csky-tdep.c:332:7: error: variable 'need_dummy_stack' set but not used [-Werror,-Wunused-but-set-variable]
int need_dummy_stack = 0;
^
/home/simark/src/binutils-gdb/gdb/csky-tdep.c:805:12: error: variable 'offset' set but not used [-Werror,-Wunused-but-set-variable]
int offset = 0;
^
Change-Id: I6703bcb50e83c50083f716f4084ef6aa30d659c4
