| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This rewrites registry.h, removing all the macros and replacing it
with relatively ordinary template classes. The result is less code
than the previous setup. It replaces large macros with a relatively
straightforward C++ class, and now manages its own cleanup.
The existing type-safe "key" class is replaced with the equivalent
template class. This approach ended up requiring relatively few
changes to the users of the registry code in gdb -- code using the key
system just required a small change to the key's declaration.
All existing users of the old C-like API are now converted to use the
type-safe API. This mostly involved changing explicit deletion
functions to be an operator() in a deleter class.
The old "save/free" two-phase process is removed, and replaced with a
single "free" phase. No existing code used both phases.
The old "free" callbacks took a parameter for the enclosing container
object. However, this wasn't truly needed and is removed here as
well.
|
|
The guile code has a couple of unused functions that touch on the
registry API. This patch removes them.
|
|
When an objfile is destroyed, types that are still in use and
allocated on that objfile are copied. A temporary hash map is created
during this process, and it is allocated on the destroyed objfile's
obstack -- which normally is fine, as that is going to be destroyed
shortly anyway.
However, this approach requires that the objfile be passed to registry
destruction, and this won't be possible in the rewritten registry.
This patch changes the copied type hash table to simply use the heap
instead. It also removes the 'objfile' parameter from
copy_type_recursive, to make this all more clear.
This patch also fixes an apparent bug in copy_type_recursive.
Previously it was copying the dynamic property list to the dying
objfile's obstack:
- = copy_dynamic_prop_list (&objfile->objfile_obstack,
However I think this is incorrect -- that obstack is about to be
destroyed.
|
|
This changes address_space to use new and delete, and makes some other
small C++-ification changes as well, like changing address_space_num
to be a method.
This patch was needed for the subsequent patch to rewrite the registry
system.
|
|
PR python/18385
v7:
This version addresses the issues pointed out by Tom.
Added nullchecks for Python object creations.
Changed from using PyLong_FromLong to the gdb_py-versions.
Re-factored some code to make it look more cohesive.
Also added the more safe Python reference count decrement PY_XDECREF,
even though the BreakpointLocation type is never instantiated by the
user (explicitly documented in the docs) decrementing < 0 is made
impossible with the safe call.
Tom pointed out that using the policy class explicitly to decrement a
reference counted object was not the way to go, so this has instead been
wrapped in a ref_ptr that handles that for us in blocpy_dealloc.
Moved macro from py-internal to py-breakpoint.c.
Renamed section at the bottom of commit message "Patch Description".
v6:
This version addresses the points Pedro gave in review to this patch.
Added the attributes `function`, `fullname` and `thread_groups`
as per request by Pedro with the argument that it more resembles the
output of the MI-command "-break-list". Added documentation for these attributes.
Cleaned up left overs from copy+paste in test suite, removed hard coding
of line numbers where possible.
Refactored some code to use more c++-y style range for loops
wrt to breakpoint locations.
Changed terminology, naming was very inconsistent. Used a variety of "parent",
"owner". Now "owner" is the only term used, and the field in the
gdb_breakpoint_location_object now also called "owner".
v5:
Changes in response to review by Tom Tromey:
- Replaced manual INCREF/DECREF calls with
gdbpy_ref ptrs in places where possible.
- Fixed non-gdb style conforming formatting
- Get parent of bploc increases ref count of parent.
- moved bploc Python definition to py-breakpoint.c
The INCREF of self in bppy_get_locations is due
to the individual locations holding a reference to
it's owner. This is decremented at de-alloc time.
The reason why this needs to be here is, if the user writes
for instance;
py loc = gdb.breakpoints()[X].locations[Y]
The breakpoint owner object is immediately going
out of scope (GC'd/dealloced), and the location
object requires it to be alive for as long as it is alive.
Thanks for your review, Tom!
v4:
Fixed remaining doc issues as per request
by Eli.
v3:
Rewritten commit message, shortened + reworded,
added tests.
Patch Description
Currently, the Python API lacks the ability to
query breakpoints for their installed locations,
and subsequently, can't query any information about them, or
enable/disable individual locations.
This patch solves this by adding Python type gdb.BreakpointLocation.
The type is never instantiated by the user of the Python API directly,
but is produced by the gdb.Breakpoint.locations attribute returning
a list of gdb.BreakpointLocation.
gdb.Breakpoint.locations:
The attribute for retrieving the currently installed breakpoint
locations for gdb.Breakpoint. Matches behavior of
the "info breakpoints" command in that it only
returns the last known or currently inserted breakpoint locations.
BreakpointLocation contains 7 attributes
6 read-only attributes:
owner: location owner's Python companion object
source: file path and line number tuple: (string, long) / None
address: installed address of the location
function: function name where location was set
fullname: fullname where location was set
thread_groups: thread groups (inferiors) where location was set.
1 writeable attribute:
enabled: get/set enable/disable this location (bool)
Access/calls to these, can all throw Python exceptions (documented in
the online documentation), and that's due to the nature
of how breakpoint locations can be invalidated
"behind the scenes", either by them being removed
from the original breakpoint or changed,
like for instance when a new symbol file is loaded, at
which point all breakpoint locations are re-created by GDB.
Therefore this patch has chosen to be non-intrusive:
it's up to the Python user to re-request the locations if
they become invalid.
Also there's event handlers that handle new object files etc, if a Python
user is storing breakpoint locations in some larger state they've
built up, refreshing the locations is easy and it only comes
with runtime overhead when the Python user wants to use them.
gdb.BreakpointLocation Python type
struct "gdbpy_breakpoint_location_object" is found in python-internal.h
Its definition, layout, methods and functions
are found in the same file as gdb.Breakpoint (py-breakpoint.c)
1 change was also made to breakpoint.h/c to make it possible
to enable and disable a bp_location* specifically,
without having its LOC_NUM, as this number
also can change arbitrarily behind the scenes.
Updated docs & news file as per request.
Testsuite: tests the .source attribute and the disabling of
individual locations.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18385
Change-Id: I302c1c50a557ad59d5d18c88ca19014731d736b0
|
|
Fix:
In gdb_mbuild.sh line 174:
continue
^------^ SC2104 (error): In functions, use return instead of continue.
Change-Id: I5ce95b01359c5cfbb1612f2f48b80bfeea66c96c
|
|
|
|
|
|
gprofng/ChangeLog
2022-07-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/29368
* configure.ac: Check for the makeinfo version.
* configure: Rebuild.
|
|
Commit 05c06f318fd9a112529dfc313e6512b399a645e4 enabled GDB to access
memory while threads are running. It did this by accessing
/proc/PID/task/LWP/mem.
Unfortunately, this interface is not implemented for writing in older
kernels (such as RHEL6). This means that GDB is unable to insert
breakpoints on these hosts:
$ ./gdb -q gdb -ex start
Reading symbols from gdb...
Temporary breakpoint 1 at 0x40fdd5: file ../../src/gdb/gdb.c, line 28.
Starting program: /home/rhel6/fsf/linux/gdb/gdb
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x40fdd5
(gdb)
Before this patch, linux_proc_xfer_memory_partial (previously called
linux_proc_xfer_partial) would return TARGET_XFER_EOF if the write to
/proc/PID/mem failed. [More specifically, linux_proc_xfer_partial
would not "bother for one word," but the effect is the essentially
same.]
This status was checked by linux_nat_target::xfer_partial, which would
then fallback to using ptrace to perform the operation.
This is the specific hunk that removed the fallback:
- xfer = linux_proc_xfer_partial (object, annex, readbuf, writebuf,
- offset, len, xfered_len);
- if (xfer != TARGET_XFER_EOF)
- return xfer;
+ return linux_proc_xfer_memory_partial (readbuf, writebuf,
+ offset, len, xfered_len);
+ }
return inf_ptrace_target::xfer_partial (object, annex, readbuf, writebuf,
offset, len, xfered_len);
This patch makes linux_nat_target::xfer_partial go straight to writing
memory via ptrace if writing via /proc/pid/mem is not possible in the
running kernel, enabling GDB to insert breakpoints on these older
kernels. Note that a recent patch changed the return status from
TARGET_XFER_EOF to TARGET_XFER_E_IO.
Tested on {unix,native-gdbserver,native-extended-gdbserver}/-m{32,64}
on x86_64, s390x, aarch64, and ppc64le.
Change-Id: If1d884278e8c4ea71d8836bedd56e6a6c242a415
|
|
Probe whether /proc/pid/mem is writable, by using it to write to a GDB
variable. This will be used in the following patch to avoid falling
back to writing to inferior memory with ptrace if /proc/pid/mem _is_
writable.
Change-Id: If87eff0b46cbe5e32a583e2977a9e17d29d0ed3e
|
|
According to LoongArch ELF ABI specification [1], handle the function
return value of various types.
[1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_return_values
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
Fix some code style issues suggested by Tom Tromey and Andrew Burgess,
thank you.
(1) Put an introductory comment to explain the purpose for some functions.
(2) Modify the the attribute code to make it portable.
(3) Remove globals and pass pointers to locals.
(4) Remove "*" in the subsequent comment lines.
(5) Put two spaces before "{" and "}".
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
PR 29411
* configure.tgt (ac_default_ld_warn_rwx_segments): Disable for
sparc-solaris configurations.
|
|
When running test-case gdb.opt/inline-small-func.exp with clang 12.0.1, I run
into:
...
gdb compile failed, /usr/bin/ld: inline-small-func0.o: in function `main':
inline-small-func.c:21: undefined reference to `callee'
clang-12.0: error: linker command failed with exit code 1 \
(use -v to see invocation)
UNTESTED: gdb.opt/inline-small-func.exp: failed to prepare
...
Fix this by using __attribute__((always_inline)).
Tested on x86_64-linux.
|
|
Three pppc32 ld tests fail when spe support is included in the linker
due to this snippet in ld/emulparams/elf32ppc.sh.
if grep -q 'ld_elf32_spu_emulation' ldemul-list.h; then
DATA_START_SYMBOLS="${RELOCATING+*crt1.o(.data .data.* .gnu.linkonce.d.*)
PROVIDE (__spe_handle = .);
*(.data.spehandle)
. += 4 * (DEFINED (__spe_handle) || . != 0);}"
fi
* testsuite/ld-powerpc/tlsexe32.r: Pass with .data section present.
* testsuite/ld-powerpc/tlsexe32no.r: Likewise.
* testsuite/ld-powerpc/tlsso32.r: Likewise.
|
|
I tried building GDB on GNU/Hurd, and ran into this error:
CXX gnu-nat.o
gnu-nat.c: In member function ‘virtual int gnu_nat_target::find_memory_regions(find_memory_region_ftype, void*)’:
gnu-nat.c:2620:21: error: too few arguments to function
2620 | (*func) (last_region_address,
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
2621 | last_region_end - last_region_address,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2622 | last_protection & VM_PROT_READ,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2623 | last_protection & VM_PROT_WRITE,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2624 | last_protection & VM_PROT_EXECUTE,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2625 | 1, /* MODIFIED is unknown, pass it as true. */
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2626 | data);
| ~~~~~
gnu-nat.c:2635:13: error: too few arguments to function
2635 | (*func) (last_region_address, last_region_end - last_region_address,
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2636 | last_protection & VM_PROT_READ,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2637 | last_protection & VM_PROT_WRITE,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2638 | last_protection & VM_PROT_EXECUTE,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2639 | 1, /* MODIFIED is unknown, pass it as true. */
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2640 | data);
| ~~~~~
make[2]: *** [Makefile:1926: gnu-nat.o] Error 1
This is because in this commit:
commit 68cffbbd4406b4efe1aa6e18460b1d7ca02549f1
Date: Thu Mar 31 11:42:35 2022 +0100
[AArch64] MTE corefile support
Added a new argument to find_memory_region_ftype, but did not pass it to
the function in gnu-nat.c. Fix this by passing memory_tagged as false.
As Luis pointed out, similar bugs may also appear on FreeBSD and NetBSD,
and I have reproduced them on both systems. This patch fixes them
incidentally.
Tested by rebuilding on GNU/Hurd, FreeBSD/amd64 and NetBSD/amd64.
|
|
I ran into this error when building GDB on NetBSD:
CXX netbsd-nat.o
netbsd-nat.c: In member function 'virtual bool nbsd_nat_target::info_proc(const char*, info_proc_what)':
netbsd-nat.c:314:3: error: 'gdb_argv' was not declared in this scope
gdb_argv built_argv (args);
^~~~~~~~
netbsd-nat.c:314:3: note: suggested alternative: 'gdbarch'
gdb_argv built_argv (args);
^~~~~~~~
gdbarch
netbsd-nat.c:315:7: error: 'built_argv' was not declared in this scope
if (built_argv.count () == 0)
^~~~~~~~~~
netbsd-nat.c:315:7: note: suggested alternative: 'buildargv'
if (built_argv.count () == 0)
^~~~~~~~~~
buildargv
gmake[2]: *** [Makefile:1893: netbsd-nat.o] Error 1
Fix this by adding the missing header file, as it is obvious.
Tested by rebuilding on NetBSD/amd64.
|
|
|
|
After the commit:
commit 08106042d9f5fdff60c129bf33190639f1a98b2a
Date: Thu May 19 13:20:17 2022 +0100
gdb: move the type cast into gdbarch_tdep
GDB would no longer build using g++ 4.8. The issue appears to be some
confusion caused by GDB having 'struct gdbarch_tdep', but also a
templated function called 'gdbarch_tdep'. Prior to the above commit
the gdbarch_tdep function was not templated, and this compiled just
fine. Note that the above commit compiles just fine with later
versions of g++, so this issue was clearly fixed at some point, though
I've not tried to track down exactly when.
In this commit I propose to fix the g++ 4.8 build problem by renaming
'struct gdbarch_tdep' to 'struct gdbarch_tdep_base'. This rename
better represents that the struct is only ever used as a base class,
and removes the overloading of the name, which allows GDB to build
with g++ 4.8.
I've also updated the comment on 'struct gdbarch_tdep_base' to fix a
typo, and the comment on the 'gdbarch_tdep' function, to mention that
in maintainer mode a run-time type check is performed.
|
|
|
|
The varobj_invalidate function is meant to be called when restarting a
process, and check at this point if some of the previously existing
varobj can be recreated in the context of the new process.
Two kind of varobj are subject to re-creation: global varobj (i.e.
varobj which reference a global variable), and floating varobj (i.e.
varobj which are always re-evaluated in the context of whatever is
the currently selected frame at the time of evaluation).
However, in the re-creation process, the varobj_invalidate_iter
recreates floating varobj as non-floating, due to an invalid parameter.
This patches fixes this and adds an assertion to check that if a varobj
is indeed recreated, it matches the original varobj "floating" property.
Another issue is that if at this recreation time the expression watched
by the floating varobj is not in scope, then the varobj is marked as
invalid. If later the user selects a frame where the expression becomes
valid, the varobj remains invalid and this is wrong. This patch also
make sure that floating varobj are not invalidated if they cannot be
evaluated.
The last important thing to note is that due to the previous patch, when
varobj_invalidate is executed (in the context of a new process), any
global var have already been invalidated (this has been done when the
objfile it referred to got invalidated). As a consequence,
varobj_invalidate tries to recreate vars which are already marked as
invalid. This does not entirely feels right, but I keep this behavior
for backward compatibility.
Tested on x86_64-linux
|
|
Varobj object contains references to types, variables (i.e. struct
variable) and expression. All of those can reference data on an
objfile's obstack. It is possible for this objfile to be deleted (and
the obstack to be feed), while the varobj remains valid. Later, if the
user uses the varobj, this will result in a use-after-free error. With
address sanitizer build, this leads to a plain error. For non address
sanitizer build we might see undefined behaviour, which manifest
themself as assertion failures when accessing data backed by feed
memory.
This can be observed if we create a varobj that refers to ta symbol in a
shared library, after either the objfile gets reloaded (using the `file`
command) or after the shared library is unloaded (with a call to dlclose
for example).
This patch fixes those issues by:
- Adding cleanup procedure to the free_objfile observable. When
activated this observer clears expressions referencing the objfile
being freed, and removes references to blocks belonging to this
objfile.
- Adding varobj support in the `preserve_values` (gdb.value.c). This
ensures that before the objfile is unloaded, any type owned by the
objfile referenced by the varobj is replaced by an equivalent type
not owned by the objfile. This process is done here instead of in the
free_objfile observer in order to reuse the type hash table already
used for similar purpose when replacing types of values kept in the
value history.
This patch also makes sure to keep a reference to the expression's
gdbarch and language_defn members when the varobj->root->exp is
initialized. Those structures outlive the objfile, so this is safe.
This is done because those references might be used initialize a python
context even after exp is invalidated. Another approach could have been
to initialize the python context with default gdbarch and language_defn
(i.e. nullptr) if expr is NULL, but since we might still try to display
the value which was obtained by evaluating exp when it was still valid,
keeping track of the context which was used at this time seems
reasonable.
Tested on x86_64-Linux.
Co-Authored-By: Pedro Alves <pedro@palves.net>
|
|
With the CLI testsuite's runto proc, we can pass "allow-pending" as an
option, like:
runto func allow-pending
That is currently not possible with MI's mi_runto, however. This
patch makes it possible, by adding a new "-pending" option to
mi_runto.
A pending breakpoint shows different MI attributes compared to a
breakpoint with a location, so the regexp returned by
mi_make_breakpoint isn't suitable. Thus, add a new
mi_make_breakpoint_pending proc for pending breakpoints.
Tweak mi_runto to let it take and pass down arguments.
Change-Id: I185fef00ab545a1df2ce12b4dbc3da908783a37c
|
|
|
|
gprofng/Changelog:
2022-07-22 Ruud van der Pas <ruud.vanderpas@oracle.com>
PR gprofng/29356
* gp-display-html/gp-display-html.in: fixed a problem to execute
gp-display-text in case gprofng is not included in the search
path.
|
|
gprofng/Changelog:
2022-07-22 Ruud van der Pas <ruud.vanderpas@oracle.com>
PR gprofng/29392
* gp-display-html/gp-display-html.in: modified a regex, plus the
code to handle the results; renamed a variable to improve the
consistency in naming.
|
|
gprofng/Changelog:
2022-07-22 Ruud van der Pas <ruud.vanderpas@oracle.com>
PR gprofng/29353
* gp-display-html/gp-display-html.in: fixed a problem in the
generation of html for the disassembly where instructions
without arguments were not handled correctly.
|
|
non-portable
gprofng/Changelog:
2022-07-22 Ruud van der Pas <ruud.vanderpas@oracle.com>
PR gprofng/29352
* gp-display-html/gp-display-html.in: the hex subroutine from
the bigint module is now used.
|
|
gprofng/Changelog:
2022-07-22 Ruud van der Pas <ruud.vanderpas@oracle.com>
PR gprofng/29351
* gp-display-html/gp-display-html.in: the dynamic loading of
modules occurred too early, resulting in the generation of the
man page to fail in case a module is missing; the loading part is
now done somewhat later in the execution to avoid this problem.
|
|
GDB uses the environment variable PYTHONDONTWRITEBYTECODE to
determine whether or not to write the result of byte-compiling
python modules when the "python dont-write-bytecode" setting
is "auto". Simon noticed that GDB's implementation doesn't
follow the Python documentation.
At present, GDB only checks for the existence of this environment
variable. That is not sufficient though. Regarding
PYTHONDONTWRITEBYTECODE, this document...
https://docs.python.org/3/using/cmdline.html
...says:
If this is set to a non-empty string, Python won't try to write
.pyc files on the import of source modules.
This commit fixes GDB's handling of PYTHONDONTWRITEBYTECODE by adding
an empty string check.
This commit also corrects the set/show command documentation for
"python dont-write-bytecode". The current doc was just a copy
of that for set/show python ignore-environment.
During his review of an earlier version of this patch, Eli Zaretskii
asked that the help text that I proposed for "set/show python
dont-write-bytecode" be expanded. I've done that in addition to
clarifying the documentation of this option in the GDB manual.
|
|
After this commit:
commit 81384924cdcc9eb2676dd9084b76845d7d0e0759
Date: Tue Apr 5 11:06:16 2022 +0100
gdb: have gdb_disassemble_info carry 'this' in its stream pointer
The disassemble_info::stream field will no longer be a ui_file*. That
commit failed to update one location in py-disasm.c though.
While running some tests using the Python disassembler API, I
triggered a call to gdbpy_disassembler::print_address_func, and, as I
had compiled GDB with the undefined behaviour sanitizer, GDB crashed
as the code currently (incorrectly) casts the stream field to be a
ui_file*.
In this commit I fix this error.
In order to test this case I had to tweak the existing test case a
little. I also spotted some debug printf statements in py-disasm.py,
which I have removed.
|
|
Simon pointed out that gdb_printing_disassembler::m_in_comment can be
used uninitialised by the Python disassembler API code. This issue
was spotted when GDB was built with the undefined behaviour sanitizer,
and causes the gdb.python/py-disasm.exp test to fail like this:
(gdb) PASS: gdb.python/py-disasm.exp: global_disassembler=GlobalPreInfoDisassembler: python add_global_disassembler(GlobalPreInfoDisassembler)
disassemble main
Dump of assembler code for function main:
0x0000555555555119 <+0>: push %rbp
0x000055555555511a <+1>: mov %rsp,%rbp
0x000055555555511d <+4>: nop
/home/user/src/binutils-gdb/gdb/disasm.h:144:12: runtime error: load of value 118, which is not a valid value for type 'bool'
The problem is that in disasmpy_builtin_disassemble we create a new
instance of gdbpy_disassembler, which is a sub-class of
gdb_printing_disassembler, however, the m_in_comment field is never
initialised.
This commit fixes the issue by providing a default initialisation
value for m_in_comment in disasm.h. As we only ever disassemble a
single instruction in disasmpy_builtin_disassemble then we don't need
to worry about reseting m_in_comment back to false after the single
instruction has been disassembled.
With this commit the above issue is resolved and
gdb.python/py-disasm.exp now passes.
|
|
When GCC 12 is used to build binutils with -O0, the following 2 tests
failed:
FAIL: Conflicted data syms, partially indexed, stripped, with variables
FAIL: Conflicted data syms, partially indexed, stripped
Compile 2 tests with -O2 to avoid test failures.
PR ld/29378
* testsuite/ld-ctf/data-func-conflicted-vars.d: Compile with -O2.
* testsuite/ld-ctf/data-func-conflicted.d: Likewise.
|
|
Attribute gcc_struct is not implemented in Clang targeting Windows, so
add a fallback standard-conforming implementation based on arrays.
I ran the testsuite on x86_64 GNU/Linux with this implementation
forced, and saw no regressions.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29373
Change-Id: I023315ee03622c59c397bf4affc0b68179c32374
|
|
For PR gdb/29373, I wrote an alternative implementation of struct
packed that uses a gdb_byte array for internal representation, needed
for mingw+clang. While adding that, I wrote some unit tests to make
sure both implementations behave the same. While at it, I implemented
all relational operators. This commit adds said unit tests and
relational operators. The alternative gdb_byte array implementation
will come next.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29373
Change-Id: I023315ee03622c59c397bf4affc0b68179c32374
|
|
Building GDB on mingw/gcc hosts is currently broken, due to a static
assertion failure in gdbsupport/packed.h:
In file included from ../../../../../binutils-gdb/gdb/../gdbsupport/common-defs.h:201,
from ../../../../../binutils-gdb/gdb/defs.h:28,
from ../../../../../binutils-gdb/gdb/dwarf2/read.c:31:
../../../../../binutils-gdb/gdb/../gdbsupport/packed.h: In instantiation of 'packed<T, Bytes>::packed(T) [with T = dwarf_unit_type; long long unsigned int Bytes = 1]':
../../../../../binutils-gdb/gdb/dwarf2/read.h:181:74: required from here
../../../../../binutils-gdb/gdb/../gdbsupport/packed.h:41:40: error: static assertion failed
41 | gdb_static_assert (sizeof (packed) == Bytes);
| ~~~~~~~~~~~~~~~~^~~~~~~~
../../../../../binutils-gdb/gdb/../gdbsupport/gdb_assert.h:27:48: note: in definition of macro 'gdb_static_assert'
27 | #define gdb_static_assert(expr) static_assert (expr, "")
| ^~~~
../../../../../binutils-gdb/gdb/../gdbsupport/packed.h:41:40: note: the comparison reduces to '(4 == 1)'
41 | gdb_static_assert (sizeof (packed) == Bytes);
| ~~~~~~~~~~~~~~~~^~~~~~~~
The issue is that mingw gcc defaults to "-mms-bitfields", which
affects how bitfields are laid out. We can however tell GCC that we
want the regular GCC layout instead using attribute gcc_struct.
Attribute gcc_struct is not implemented in "clang -target
x86_64-pc-windows-gnu", so that will need a different fix.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29373
Change-Id: I023315ee03622c59c397bf4affc0b68179c32374
|
|
For a long time I've had this in my ~/.gitconfig:
[core]
whitespace = space-before-tab,indent-with-non-tab,trailing-space
which causes git to show me if I muck up and use spaces instead of
tabs, or leave in trailing whitespace. I find this really useful.
I recently proposed adding something like this to the .gitattributes
files for the GDB sub-directories (gdb, gdbsupport, and gdbserver)[1],
however, the question was asked - couldn't this be done at the top
level?
So, in this commit, I propose to update the top-level .gitattributes
file, after this commit, any git diff on a C, C++, Expect, or TCL
source file, will highlight the following whitespace errors:
(a) Use a space before a tab at the start of a line,
(b) Use of spaces where a tab could be used at the start of a line,
and
(c) Any trailing whitespace.
Errors are only highlighted in the diff on new or modified lines, so
you don't get spammed for errors on context lines that you haven't
modified.
The only downside I see to adding this at the top level is if there
are any sub-directories that don't follow the tabs/spaces indentation
rules very well already, in those directories you'll end up hitting
issues any time you edit a line. For GDB we're usually pretty good,
so having this highlighting isn't an issue.
[1] https://sourceware.org/pipermail/gdb-patches/2022-July/190843.html
|
|
For Arm Cortex-M33 with security extensions, there are 4 different
stack pointers (msp_s, msp_ns, psp_s, psp_ns), without security
extensions and for other Cortex-M targets, there are 2 different
stack pointers (msp and psp).
With this patch, sp will always be in sync with one of the real stack
pointers on Arm targets that contain more than one stack pointer.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
|
|
As the register numbers for the alternative Arm SP registers are not
constant, it's not possible to use switch statement to define the
rules. In order to not have a mix, replace the few existing
switch statements with regular if-else if statements
|
|
windows_nat_target::detach has a variable 'detached' that is only set
after a call to 'error'. However, this can't happen because 'error'
throws an exception.
This patch removes the dead code.
|
|
In commit:
commit 4f46c0bc36471b725de0253bfec1a42a36e2c5c5
Date: Mon Jul 4 17:45:25 2022 +0100
opcodes: add new sub-mnemonic disassembler style
I added a new disassembler style dis_style_sub_mnemonic, but forgot to
add GDB support for this style. Fix this oversight in this commit.
|
|
This commit adds disassembler styling to the libopcodes ppc
disassembler. This conversion was pretty straight forward, I just
converted the fprintf_func calls to fprintf_styled_func calls and
added an appropriate style.
For testing the new styling I just assembled then disassembled the
source files in gas/testsuite/gas/ppc and manually checked that the
styling looked reasonable.
I think the only slightly weird case was how things like '4*cr1+eq'
are styled. As best I can tell, this construct, used for example in
this instruction:
crand 4*cr1+lt,4*cr1+gt,4*cr1+eq
is used to access a field of a control register. I initially tried
styling this whole construct as a register[1], but during review it
was suggested that instead different parts of the text should have
different styles. In this commit I propose styling '4*cr1+lt' like
this:
4 - immediate,
* - text,
cr1 - register
+ - text
lt - sub-mnemonic
If the user does not request styled output from objdump, then there
should be no change in the disassembler output after this commit.
[1] https://sourceware.org/pipermail/binutils/2022-July/121771.html
|
|
When adding libopcodes disassembler styling support for AArch64, it
feels like the results would be improved by having a new sub-mnemonic
style. This will be used in cases like:
add w16, w7, w1, uxtb #2
^^^^----- Here
And:
cinc w0, w1, ne
^^----- Here
This commit just adds the new style, and prepares objdump to handle
the style. A later commit will add AArch64 styling, and will actually
make use of the style.
As this style is currently unused, there should be no user visible
changes after this commit.
|
|
gas/testsuite/gas/all/
gas.exp
gas/testsuite/gas/loongarch/
jmp_op.d
jmp_op.s
macro_op.d
macro_op.s
macro_op_32.d
macro_op_32.s
macro_op_large_abs.d
macro_op_large_abs.s
macro_op_large_pc.d
macro_op_large_pc.s
reloc.d
reloc.s
ld/testsuite/ld-elf/
pr26936.d
shared.exp
ld/testsuite/ld-loongarch-elf/
attr-ifunc-4.c
attr-ifunc-4.out
disas-jirl.d
ifunc.exp
jmp_op.d
jmp_op.s
libnopic-global.s
macro_op.d
macro_op.s
macro_op_32.d
macro_op_32.s
nopic-global-so.rd
nopic-global-so.sd
nopic-global.out
nopic-global.s
nopic-global.sd
nopic-global.xd
nopic-local.out
nopic-local.rd
nopic-local.s
nopic-local.sd
nopic-local.xd
nopic-weak-global-so.rd
nopic-weak-global-so.sd
nopic-weak-global.out
nopic-weak-global.s
nopic-weak-global.sd
nopic-weak-global.xd
nopic-weak-local.out
nopic-weak-local.rd
nopic-weak-local.s
nopic-weak-local.sd
nopic-weak-local.xd
pic.exp
pic.ld
|
|
Some R_LARCH_64 in section .eh_frame will to generate
R_LARCH_NONE, we change relocation to R_LARCH_32_PCREL
from R_LARCH_64 in setction .eh_frame and not generate
dynamic relocation for R_LARCH_32_PCREL.
Add New relocate type R_LARCH_32_PCREL for .eh_frame.
include/elf/
loongarch.h
bfd/
bfd/bfd-in2.h
libbfd.h
reloc.c
elfxx-loongarch.c
elfnn-loongarch.c
gas/config/
tc-loongarch.c
binutils/
readelf.c
ld/testsuite/ld-elf/
eh5.d
|
|
Delete R_LARCH_IRELATIVE from dynamic loader (glibc ld.so) when
loading lazy function (rela.plt section).
In dynamic programes, move ifunc dynamic relocate info to section
srelgot from srelplt.
bfd/
elfnn-loongarch.c
|
|
Generate new relocate types while use new macro insns.
gas/config/
loongarch-lex.h
loongarch-parse.y
tc-loongarch.c
tc-loongarch.h
|
|
opcodes: Replace old insns with news and generate new relocate types
while macro insns expanding.
opcodes/
loongarch-opc.c
|
|
Define new reloc types according to linker needs.
include/elf/
loongarch.h
bfd/
bfd-in2.h
libbfd.h
reloc.c
elfnn-loongarch.c
elfxx-loongarch.c
elfxx-loongarch.h
|
