Mark pointed out that my recent addrmap C++-ficiation changes caused a
regression in the self-tests. This patch fixes the problem by
updating this test not to allocate the mutable addrmap on an obstack.
While working on addrmaps, I noticed that psymtab_addrmap is no longer
needed now. It was introduced in ancient times as an optimization for
DWARF, but no other symbol reader was ever updated to use it. Now
that DWARF does not use psymtabs, it can be deleted.
Mutable addrmaps currently require an obstack. This was probably done
to avoid having to call splay_tree_delete, but examination of the code
shows that all mutable obstacks have a limited lifetime -- now it's
simple to treat them as ordinary C++ objects, in some cases
stack-allocating them, and have a destructor to make the needed call.
This patch implements this change.
This is a simply C++-ification of the basics of addrmap: it uses
virtual methods rather than a table of function pointers, and it
changes the concrete implementations to be subclasses.
Prior to c6ca3dab dropping support for Cygwin 1.5, __USEWIDE was not
defined for Cygwin 1.5. After that, it's always defined if __CYGWIN__
is, so remove __USEWIDE conditionals inside __CYGWIN__ conditionals.
With the registry rewrite series, on Fedora 34, I started seeing this
error in xcoffread.c:
../../binutils-gdb/gdb/xcoffread.c: In function ‘void read_xcoff_symtab(objfile*, legacy_psymtab*)’:
../../binutils-gdb/gdb/xcoffread.c:948:25: error: ‘main_aux’ is used uninitialized [-Werror=uninitialized]
948 | union internal_auxent fcn_aux_saved = main_aux;
| ^~~~~~~~~~~~~
../../binutils-gdb/gdb/xcoffread.c:933:25: note: ‘main_aux’ declared here
933 | union internal_auxent main_aux;
| ^~~~~~~~
I don't know why this error started suddenly... that seems weird,
because it's not obviously related to the changes I made.
Looking into it, it seems this line was intended to avoid a similar
warning -- but since 'main_aux' is uninitialized at the point where it
is used, this fix was incomplete.
This patch avoids the warning by initializing using "{}". I'm
checking this in.
The if statement in case gdb_sys_ioctl in function
record_linux_system_call in file gdb/linux-record.c is as follows:
if (tmpulongest == tdep->ioctl_FIOCLEX
|| tmpulongest == tdep->ioctl_FIONCLEX
....
|| tmpulongest == tdep->ioctl_TCSETSW
...
}
The PowerPC ioctl value for ioctl_TCSETW is 0x802c7415. The variable
ioctl_TCSETW is defined in gdb/linux-record.h as an int. The TCSETW value
has the MSB set to one so it is a negative integer. The comparison of the
unsigned long value tmpulongest to a negative integer value for
ioctl_TCSETSW fails.
This patch changes the declarations for the ioctl_* values in struct
linux_record_tdep to unsigned long to fix the comparisons between
tmpulongest and the tdep->ioctl_* values.
An additional test gdb.reverse/test_ioctl_TCSETSW.exp is added to verify
the gdb record_linux_system_call() if statement for the ioctl TCSETSW
succeeds.
This patch has been tested on Power 10 and Intel with no test failures.
Some of the ioctl numbers are based on the size of kernel termios structure.
Currently the PowerPC GDB definitions are "hard coded" into the ioctl
number.
The current PowerPC values for TCGETS, TCSETS, TCSETSW and TCSETSF are
defined in gdb/ppc-linux-tdep.c as:
record_tdep->ioctl_TCGETS = 0x403c7413;
record_tdep->ioctl_TCSETS = 0x803c7414;
record_tdep->ioctl_TCSETSW = 0x803c7415;
record_tdep->ioctl_TCSETSF = 0x803c7416;
Where the termios structure size is in hex digits [5:4] as 0x3c.
The definition for the PowerPC termios structure is given in:
arch/powerpc/include/uapi/asm/termbits.h
The size of the termios data structure in this file is 0x2c not 0x3c.
This patch changes the hex digits for the size of the PowerPC termios size
in the ioctl values for TCGETS, TCSETS, TCSETSW and TCSETSF to 0x2c.
This patch also changes the hard coding to generate the number based on a
it easier to update the ioctl numbers.
Since pretty much forever the get_compiler_info function has included
these lines:
# Most compilers will evaluate comparisons and other boolean
# operations to 0 or 1.
uplevel \#0 { set true 1 }
uplevel \#0 { set false 0 }
These define global variables true (to 1) and false (to 0).
It seems odd to me that these globals are defined in
get_compiler_info, I guess maybe the original thinking was that if a
compiler had different true/false values then we would detect it there
and define true/false differently.
I don't think we should be bundling this logic into get_compiler_info,
it seems weird to me that in order to use $true/$false a user needs to
first call get_compiler_info.
It would be better I think if each test script that wants these
variables just defined them itself, if in the future we did need
different true/false values based on compiler version then we'd just
do:
if { [test_compiler_info "some_pattern"] } {
# Defined true/false one way...
} else {
# Defined true/false another way...
}
But given the current true/false definitions have been in place since
at least 1999, I suspect this will not be needed any time soon.
Given that the definitions of true/false are so simple, right now my
suggestion is just to define them in each test script that wants
them (there's not that many). If we ever did need more complex logic
then we can always add a function in gdb.exp that sets up these
globals, but that seems overkill for now.
There should be no change in what is tested after this commit.
This variable is useful when exercising AArch64 multi-arch support (debugging
32-bit AArch32 executables).
Unfortunately it isn't well documented. This patch adds information about it
and explains how to use it.
With gcc-12, I get for test-case gdb.base/vla-struct-fields.exp:
...
(gdb) print inner_vla_struct_object_size == sizeof(inner_vla_struct_object)^M
$7 = 1^M
(gdb) XPASS: gdb.base/vla-struct-fields.exp: size of inner_vla_struct_object
...
Fix this by limiting the xfailing to gcc-11 and earlier. Also, limit the
xfailing to the equality test.
Tested on x86_64-linux.
On openSUSE Tumbleweed with gcc-12, I run into a timeout:
...
(gdb) print value^M
Multiple matches for value^M
[0] cancel^M
[1] ada.strings.maps.value (<ref> ada.strings.maps.character_mapping; \
character) return character at a-strmap.adb:599^M
[2] pck.value at src/gdb/testsuite/gdb.ada/ghost/pck.ads:17^M
[3] system.object_reader.value (<ref> system.object_reader.object_symbol) \
return system.object_reader.uint64 at s-objrea.adb:2279^M
[4] system.traceback.symbolic.value (system.address) return string at \
s-trasym.adb:200^M
> FAIL: gdb.ada/ghost.exp: print value (timeout)
print ghost_value^M
Argument must be choice number^M
(gdb) FAIL: gdb.ada/ghost.exp: print ghost_value
...
Fix this by prefixing value (as well as the other printed values) with the
package name:
...
(gdb) print pck.value^M
...
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29055
I noticed that the Python event documentation referred to the event's
"breakpoint" field as a function, whereas it is actually an attribute.
This patch fixes the error.
GDB's ability to run 32-bit ARM processes on an AArch64 native target
is currently broken. The test gdb.multi/multi-arch.exp currently
fails with a timeout.
The cause of these problems is the following three functions:
aarch64_linux_nat_target::thread_architecture
aarch64_linux_nat_target::fetch_registers
aarch64_linux_nat_target::store_registers
What has happened, over time, is that these functions have been
modified, forgetting that any particular thread (running on the native
target) might be an ARM thread, or might be an AArch64 thread.
The problems always start with a line similar to this:
aarch64_gdbarch_tdep *tdep
= (aarch64_gdbarch_tdep *) gdbarch_tdep (inf->gdbarch);
The problem with this line is that if 'inf->gdbarch' is an ARM
architecture, then gdbarch_tdep will return a pointer to an
arm_gdbarch_tdep object, not an aarch64_gdbarch_tdep object. The
result of the above cast will, as a consequence, be undefined.
In aarch64_linux_nat_target::thread_architecture, after the undefined
cast we then proceed to make use of TDEP, like this:
if (vq == tdep->vq)
return inf->gdbarch;
Obviously at this point the result is undefined, but, if this check
returns false we then proceed with this code:
struct gdbarch_info info;
info.bfd_arch_info = bfd_lookup_arch (bfd_arch_aarch64, bfd_mach_aarch64);
info.id = (int *) (vq == 0 ? -1 : vq);
return gdbarch_find_by_info (info);
As a consequence we will return an AArch64 gdbarch object for our ARM
thread! Things go downhill from there on.
There are similar problems, with similar undefined behaviour, in the
fetch_registers and store_registers functions.
The solution is to make use of a check like this:
if (gdbarch_bfd_arch_info (inf->gdbarch)->bits_per_word == 32)
If the word size is 32 then we know we have an ARM architecture. We
just need to make sure that we perform this check before trying to
read the tdep field.
In aarch64_linux_nat_target::thread_architecture a little reordering,
and the addition of the above check allows us to easily avoid the
undefined behaviour.
For fetch_registers and store_registers I made the decision to split
each of the functions into two new helper functions, and so
aarch64_linux_nat_target::fetch_registers now calls to either
aarch64_fetch_registers or aarch32_fetch_registers, and there's a
similar change for store_registers.
One thing I had to decide was whether to place the new aarch32_*
functions into the aarch32-linux-nat.c file. In the end I decided to
NOT place the functions there, but instead leave them in
aarch64-linux-nat.c, my reasoning was this:
The existing functions in that file are shared from arm-linux-nat.c
and aarch64-linux-nat.c, this generic code to support 32-bit ARM
debugging from either native target.
In contrast, the two new aarch32 functions I have added _only_ make
sense when debugging on an AArch64 native target. These function
shouldn't be called from arm-linux-nat.c at all, and so, if we places
the functions into aarch32-linux-nat.c, the functions would be built
into a 32-bit ARM GDB, but never used.
With that said, there's no technical reason why they couldn't go in
aarch32-linux-nat.c, so if that is preferred I'm happy to move them.
After this commit the gdb.multi/multi-arch.exp passes.
Add a description of exception entry context stacking and fix next
frame offset (at 0xA8 relative to R0 location) as well as FPU
registers ones (starting at 0x68 relative to R0).
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
Small performance improvement by fetching previous SP value only
once before the loop and reuse it to avoid fetching at every
iteration.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
The previous patch that introduced the arm_cc_for_target procedure
moved the ARM_CC_FOR_TARGET global check to that procedure, but forgot
to tell tcl that ARM_CC_FOR_TARGET is a global. As a result,
specifying ARM_CC_FOR_TARGET on the command line actually does
nothing. This fixes it.
Change-Id: I4e33b7633fa665e2f7b8f8c9592a949d74a19153
ARMv7-M Architecture Reference "A2.3.1 Arm core registers" states
that LR is set to 0xffffffff on reset.
ARMv8-M Architecture Reference "B3.3 Registers" states that LR is set
to 0xffffffff on warm reset if Main Extension is implemented,
otherwise the value is unknown.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
After this commit:
commit 44d469c5f8
Date: Tue May 31 16:43:44 2022 +0200
gdb/testsuite: add Fortran compiler identification to GDB
Some regressions were noticed:
https://sourceware.org/pipermail/gdb-patches/2022-May/189673.html
The problem is associated with how compiler_info variable is cached
between calls to get_compiler_info.
Even before the above commit, get_compiler_info supported two
language, C and C++. Calling get_compiler_info would set the global
compiler_info based on the language passed as an argument to
get_compiler_info, and, in theory, compiler_info would not be updated
for the rest of the dejagnu run.
This obviously is slightly broken behaviour. If the first call to
get_compiler_info was for the C++ language then compiler_info would be
set based on the C++ compiler in use, while if the first call to
get_compiler_info was for the C language then compiler_info would be
set based on the C compiler.
This probably wasn't very noticable, assuming a GCC based test
environment then in most cases the C and C++ compiler would be the
same version.
However, if the user starting playing with CC_FOR_TARGET or
CXX_FOR_TARGET, then they might not get the behaviour they expect.
Except, to make matters worse, most of the time, the user probably
would get the behaviour they expected .... except when they didn't!
I'll explain:
In gdb.exp we try to avoid global variables leaking between test
scripts, this is done with the help of the two procs
gdb_setup_known_globals and gdb_cleanup_globals. All known globals
are recorded before a test script starts, and then, when the test
script ends, any new globals are deleted.
Normally, compiler_info is only set as a result of a test script
calling get_compiler_info or test_compiler_info. This means that the
compiler_info global will not exist when the test script starts, but
will exist when the test script end, and so, the compiler_info
variable is deleted at the end of each test.
This means that, in reality, the compiler_info is recalculated once
for each test script, hence, if a test script just checks on the C
compiler, or just checks on the C++ compiler, then compiler_info will
be correct and the user will get the behaviour they expect.
However, if a single test script tries to check both the C and C++
compiler versions then this will not work (even before the above
commit).
The situation is made worse be the behaviour or the load_lib proc.
This proc (provided by dejagnu) will only load each library once.
This means that if a library defines a global, then this global would
normally be deleted at the end of the first test script that includes
the library.
As future attempts to load the library will not actually reload it,
then the global will not be redefined and would be missing for later
test scripts that also tried to load that library.
To work around this issue we override load_lib in gdb.exp, this new
version adds all globals from the newly loaded library to the list of
globals that should be preserved (not deleted).
And this is where things get interesting for us. The library
trace-support.exp includes calls, at the file scope, to things like
is_amd64_regs_target, which cause get_compiler_info to be called.
This means that after loading the library the compiler_info global is
defined.
Our override of load_lib then decides that this new global has to be
preserved, and adds it to the gdb_persistent_globals array.
From that point on compiler_info will never be recomputed!
This commit addresses all the caching problems by doing the following:
Change the compiler_info global into compiler_info_cache global. This
new global is an array, the keys of this array will be each of the
supported languages, and the values will be the compiler version for
that language.
Now, when we call get_compiler_info, if the compiler information for
the specific language has not been computed, then we do that, and add
it to the cache.
Next, compiler_info_cache is defined by calling
gdb_persistent_global. This automatically adds the global to the list
of persistent globals. Now the cache will not be deleted at the end
of each test script.
This means that, for a single test run, we will compute the compiler
version just once for each language, this result will then be cached
between test scripts.
Finally, the legacy 'gcc_compiled' flag is now only set when we call
get_compiler_info with the language 'c'. Without making this change
the value of 'gcc_compiled' would change each time a new language is
passed to get_compiler_info. If the last language was e.g. Fortran,
then gcc_compiled might be left false.
Now that get_compiler_info might actually fail (if the language is not
handled), then we should try to handle this failure better in
test_compiler_info.
After this commit, if get_compiler_info fails then we will return a
suitable result depending on how the user called test_compiler_info.
If the user does something like:
set version [test_compiler_info "" "unknown-language"]
Then test_compiler_info will return an empty string. My assumption is
that the user will be trying to match 'version' against something, and
the empty string hopefully will not match.
If the user does something like:
if { [test_compiler_info "some_pattern" "unknown-language"] } {
....
}
Then test_compiler_info will return false which seems the obvious
choice.
There should be no change in the test results after this commit.
This commit is a minor cleanup for the two functions (in gdb.exp)
get_compiler_info and test_compiler_info.
Instead of using the empty string as the default language, and just
"knowing" that this means the C language. Make this explicit. The
language argument now defaults to "c" if not specified, and the if
chain in get_compiler_info that checks the language not explicitly
handles "c" and gives an error for unknown languages.
This is a good thing, now that the API appears to take a language, if
somebody does:
test_compiler_info "xxxx" "rust"
to check the version of the rust compiler then we will now give an
error rather than just using the C compiler and leaving the user
having to figure out why they are not getting the results they
expect.
After a little grepping, I think the only place we were explicitly
passing the empty string to either get_compiler_info or
test_compiler_info was in gdb_compile_shlib_1, this is now changed to
pass "c" as the default language.
There should be no changes to the test results after this commit.
We don't need to call get_compiler_info before calling
test_compiler_info; test_compiler_info includes a call to
get_compiler_info.
This commit cleans up lib/gdb.exp and lib/dwarf.exp a little by
removing some unneeded calls to get_compiler_info. We could do the
same cleanup throughout the testsuite, but I'm leaving that for
another day.
There should be no change in the test results after this commit.
The procedure gcc_major_version was earlier using the global variable
compiler_info to retrieve gcc's major version. This is discouraged and
(as can be read in a comment in compiler.c) compiler_info should be
local to get_compiler_info and test_compiler_info.
The preferred way of getting the compiler string is via calling
test_compiler_info without arguments. Gcc_major_version was changed to
do that.
While running the gdb.threads/tls.exp test with a GDB configured
without Python, I noticed some duplicate test names.
This is caused by a call to skip_python_tests that is within a proc
that is called multiple times by the test script. Each call to
skip_python_tests results in a call to 'unsupported', and this causes
the duplicate test names.
After this commit we now call skip_python_tests just once and place
the result into a variable. Now, instead of calling skip_python_tests
multiple times, we just check the variable.
There should be no change in what is tested after this commit.
While testing on AArch64 I spotted a duplicate test name in the
gdb.base/gnu_vector.exp test.
This commit adds a 'with_test_prefix' to resolve the duplicate.
While I was in the area I updated a 'gdb_test_multiple' call to make
use of $gdb_test_name.
There should be no change in what is tested after this commit.
The throw_perror_with_name function is not used outside of utils.c
right now. And as perror_with_name is just a wrapper around
throw_perror_with_name, then any future calls would be to
perror_with_name.
Lets make throw_perror_with_name static.
There should be no user visible changes after this commit.
I ran into this error while working on AArch64 GDB:
Unable to fetch VFP registers.: Invalid argument.
Notice the '.:' in the middle of this error message.
This is because of this call in aarch64-linux-nat.c:
perror_with_name (_("Unable to fetch VFP registers."));
The perror_with_name function take a string, and adds ': <message>' to
the end the string, so I don't think the string that we pass to
perror_with_name should end in '.'.
This commit removes all of the trailing '.' characters from
perror_with_name calls, which give more readable error messages.
I don't believe that any of these errors are tested in the
testsuite (after a little grepping).
The CU queue is a member of dwarf2_per_bfd, but it is only used when
expanding CUs. Also, the dwarf2_per_objfile destructor checks the
queue -- however, if the per-BFD object is destroyed first, this will
not work. This was pointed out Lancelot as fallout from the patch to
rewrite the registry system.
This patch avoids this problem by moving the queue to the per-objfile
object.
The i386 disassembler is pretty complex. Most disassembly is done
indirectly; operands are built into buffers within a struct instr_info
instance, before finally being printed later in the disassembly
process.
Sometimes the operand buffers are built in a different order to the
order in which they will eventually be printed.
Each operand can contain multiple components, e.g. multiple registers,
immediates, other textual elements (commas, brackets, etc).
When looking for how to apply styling I guess the ideal solution would
be to move away from the operands being a single string that is built
up, and instead have each operand be a list of "parts", where each
part is some text and a style. Then, when we eventually print the
operand we would loop over the parts and print each part with the
correct style.
But it feels like a huge amount of work to move from where we are
now to that potentially ideal solution. Plus, the above solution
would be pretty complex.
So, instead I propose a .... different solution here, one that works
with the existing infrastructure.
As each operand is built up, piece be piece, we pass through style
information. This style information is then encoded into the operand
buffer (see below for details). After this the code can continue to
operate as it does right now in order to manage the set of operand
buffers.
Then, as each operand is printed we can split the operand buffer into
chunks at the style marker boundaries, with each chunk being printed
with the correct style.
For encoding the style information I use a single character, currently
\002, followed by the style encoded as a single hex digit, followed
again by the \002 character.
This of course relies on there not being more than 16 styles, but that
is currently true, and hopefully will remain true for the foreseeable
future.
The other major concern that has arisen around this work is whether
the escape character could ever be encountered in output naturally
generated by the disassembler. If this did happen then the escape
characters would be stripped from the output, and the wrong styling
would be applied.
However, I don't believe that this is currently a problem.
Disassembler content comes from a number of sources. First there's
content that copied directly from the i386-dis.c file, this is things
like register names, and other syntax elements (brackets, commas,
etc). We can easily check that the i386-dis.c file doesn't contain
our special character.
The next source of content are immediate operands. The text for these
operands is generated by calls into libc. By selecting a
non-printable character we can be confident that this is not something
that libc will generate as part of an immediate representation.
The other output that appears to be from the disassembler is operands
that contain addresses and (possibly) symbol names. It is quite
possible that a symbol name might contain any special character we
could imagine, so is this a problem?
I don't think it is, we don't actually print address and symbol
operands through the disassembler, instead, the disassembler calls
back to the user (objdump, gdb, etc) to print the address and symbol
on its behalf. This content is printed directly to the output stream,
it does not pass through the i386 disassembler output buffers. As a
result, we never check this particular output for styling escape
characters.
In some (not very scientific) benchmarking on my machine,
disassembling a reasonably large (142M) shared library, I'm not seeing
any significant slow down in disassembler speed with this change.
Most instructions are now being fully syntax highlighted when I
disassemble using the --disassembler-color=extended-color option. I'm
sure that there are probably still a few corner cases that need fixing
up, but we can come back to them later I think.
When disassembler syntax highlighting is not being used, then there
should be no user visible changes after this commit.
The following commit changes the output format for the isel instruction on
PowerPC.
commit dd4832bf3e Introduces error in test
Author: Dmitry Selyutin <ghostmansd@gmail.com>
Date: Tue May 24 13:46:35 2022 +0000
opcodes: introduce BC field; fix isel
Per Power ISA Version 3.1B 3.3.12, isel uses BC field rather than CRB
field present in binutils sources. Also, per 1.6.2, BC has the same
semantics as BA and BB fields, so this should keep the same flags and
mask, only with the different offset.
opcodes/
* ppc-opc.c
(BC): Define new field, with the same definition as CRB field,
but with the PPC_OPERAND_CR_BIT flag present.
gas/
* testsuite/gas/ppc/476.d: Update.
* testsuite/gas/ppc/a2.d: Update.
* testsuite/gas/ppc/e500.d: Update.
* testsuite/gas/ppc/power7.d: Update.
<snip>
--- a/gas/testsuite/gas/ppc/476.d
+++ b/gas/testsuite/gas/ppc/476.d
@@ -209,7 +209,7 @@ Disassembly of section \.text:
.*: (7c 20 07 8c|8c 07 20 7c) ici 1
.*: (7c 03 27 cc|cc 27 03 7c) icread r3,r4
.*: (50 83 65 36|36 65 83 50) rlwimi r3,r4,12,20,27
-.*: (7c 43 27 1e|1e 27 43 7c) isel r2,r3,r4,28
+.*: (7c 43 27 1e|1e 27 43 7c) isel r2,r3,r4,4\*cr7\+lt
The above change breaks the gdb regression test gdb.arch/powerpc-power7.exp
on Power 7, Power 8, Power 9 and Power 10.
This patch updates the regression test gdb.arch/powerpc-power7.exp with
the new expected output for the isel instruction.
The patch has been tested on Power 7 and Power 10 to verify the patch fixes
the test.
On Aarch64, you can set ARM_CC_FOR_TARGET to point to the 32-bit
compiler to use when testing gdb.multi/multi-arch.exp and
gdb.multi/multi-arch-exec.exp. If you don't set it, then those
testcases don't run.
I guess that approximately nobody remembers to set ARM_CC_FOR_TARGET.
This commit adds a fallback. If ARM_CC_FOR_TARGET is not set, and
testing for Linux, try arm-linux-gnueabi-gcc,
arm-none-linux-gnueabi-gcc, arm-linux-gnueabihf-gcc as 32-bit
compilers, making sure that the produced executable runs on the target
machine before claiming that the compiler produces useful executables.
Change-Id: Iefe5865d5fc84b4032eaff7f4c5c61582bf75c39
I expect the encoded reloc.size field originally came from aout
r_length ecoding, but somehow went wrong for 64-bit relocs (which
should have been encoded as 3). Toss all that out, just use a byte
size instead. The changes outside of reloc.c in this patch should
make the code independent of how reloc.size is encoded.
* reloc.c (struct reloc_howto_struct): Increase size field by
one bit. Comment.
(HOWTO_RSIZE): Don't encode size.
(bfd_get_reloc_size): Adjust, and make it an inline function.
(read_reloc, write_reloc): Adjust.
* bfd-in2.h: Regenerate.
* aout-ns32k.c: Include libbfd.h.
(put_reloc): Don't use howto->size directly. Calculate r_length
using bfd_log2 and bfd_get_reloc_size.
* aoutx.h (swap_std_reloc_out): Likewise.
(aout_link_reloc_link_order): Likewise.
* i386lynx.c (swap_std_reloc_out
* mach-o-i386.c (bfd_mach_o_i386_swap_reloc_out
* pdp11.c (aout_link_reloc_link_order
* coff-arm.c (coff_arm_reloc): Don't use howto->size directly,
use bfd_get_reloc_size instead and adjust switch cases.
* coff-i386.c (coff_i386_reloc): Similarly.
* coff-x86_64.c (coff_amd64_reloc): Likewise.
* cpu-ns32k.c (do_ns32k_reloc): Likewise.
* elf32-arc.c (arc_do_relocation): Likewise.
* elf32-arm.c (elf32_arm_final_link_relocate): Likewise.
* elf32-bfin.c (bfin_bfd_reloc): Likewise.
* elf32-cr16.c (cr16_elf_final_link_relocate): Likewise.
* elf32-cris.c (cris_elf_pcrel_reloc): Likewise.
* elf32-crx.c (crx_elf_final_link_relocate): Likewise.
* elf32-csky.c (csky_elf_relocate_section): Likewise.
* elf32-d10v.c (extract_rel_addend, insert_rel_addend): Likewise.
* elf32-i386.c (elf_i386_relocate_section): Likewise.
* elf32-m32r.c (m32r_elf_generic_reloc): Likewise.
* elf32-nds32.c (nds32_elf_generic_reloc): Likewise.
* syms.c (_bfd_stab_section_find_nearest_line): Likewise.
* coff-rs6000.c (xcoff_ppc_relocate_section): Adjust howto.size.
* coff64-rs6000.c (xcoff64_ppc_relocate_section): Likewise.
These all ought to use bfd_reloc_offset_in_range. In particular, replace
the check using howto->size + 1u.
* elf32-bfin.c (bfin_pcrel24_reloc): Use bfd_reloc_offset_in_range.
(bfin_imm16_reloc, bfin_byte4_reloc, bfin_bfd_reloc),
(bfin_final_link_relocate): Likewise.
The "HOWTO size encoding" patch put 1 as the HOWTO size arg for
numerous howtos that are unused, describe dynamic relocs, are markers,
or otherwise are special purpose reloc howtos that don't care about
the size. The idea was to ensure no howto changed by inspecting
object files. Revert those changes, making them zero size.
* coff-alpha.c: Give special purpose reloc howtos a size of zero.
* coff-mcore.c, * elf-hppa.h, * elf-m10300.c, * elf32-arm.c,
* elf32-csky.c, * elf32-m32c.c, * elf32-m68k.c, * elf32-mep.c,
* elf32-mips.c, * elf32-ppc.c, * elf32-rx.c, * elf32-s390.c,
* elf32-spu.c, * elf32-tic6x.c, * elf32-tilepro.c, *elf32-vax.c,
* elf32-xtensa.c, * elf64-alpha.c, * elf64-mips.c,
* elf64-mmix.c, * elf64-ppc.c, * elf64-s390.c, * elfn32-mips.c,
* elfxx-loongarch.c, * elfxx-riscv.c, * elfxx-sparc.c,
* elfxx-tilegx.c, * som.c, * vms-alpha.c: Likewise.
