Adds two new external authors to etc/update-copyright.py to cover
bfd/ax_tls.m4, and adds gprofng to dirs handled automatically, then
updates copyright messages as follows:
1) Update cgen/utils.scm emitted copyrights.
2) Run "etc/update-copyright.py --this-year" with an extra external
author I haven't committed, 'Kalray SA.', to cover gas testsuite
files (which should have their copyright message removed).
3) Build with --enable-maintainer-mode --enable-cgen-maint=yes.
4) Check out */po/*.pot which we don't update frequently.
With old "medium" code model, we call a function with a pair of PCALAU12I
and JIRL instructions. The assembler produces something like:
8: 1a00000c pcalau12i $t0, 0
8: R_LARCH_PCALA_HI20 g
c: 4c000181 jirl $ra, $t0, 0
c: R_LARCH_PCALA_LO12 g
The linker generates a "PLT entry" for data without any diagnostic.
If "g" is a data symbol and ld with -shared option, it may load two
instructions in the PLT.
Without -shared option, loongarch_elf_adjust_dynamic_symbol can delete PLT
entry.
For R_LARCH_PCALA_HI20 relocation, linker only generate PLT entry for STT_FUNC
and STT_GNU_IFUNC symbols.
This commits changes how errors are reported from the expression
parser. Previously, parser errors were reported like this:
(gdb) p a1 +}= 432
A syntax error in expression, near `}= 432'.
(gdb) p a1 +
A syntax error in expression, near `'.
The first case is fine, a user can figure out what's going wrong, but
the second case is a little confusing; as the error occurred at the
end of the expression GDB just reports the empty string to the user.
After this commit the first case is unchanged, but the second case now
reports like this:
(gdb) p a1 +
A syntax error in expression, near the end of `a1 +'.
Which I think is clearer. There is a possible issue if the expression
being parsed is very long, GDB will repeat the whole expression. But
this issue already exists in the standard case; if the error occurs
early in a long expression GDB will repeat everything after the syntax
error. So I've not worried about this case in my new code either,
which keeps things simpler.
I did consider trying to have multi-line errors here, in the style
that gcc produces, with some kind of '~~~~~^' marker on the second
line to indicate where the error occurred; but I rejected this due to
the places in GDB where we catch an error and repackage the message
within some longer string, I don't think multi-line error messages
would work well in that case. At a minimum it would require some
significant work in order to make all our error handling multi-line
aware.
I've added a couple of extra tests in gdb.base/exprs.exp.
Approved-By: John Baldwin <jhb@FreeBSD.org>
Many (all?) of the expression parsers implement yyerror to handle
parser errors, and all of these functions are basically identical.
This commit adds a new parser_state::parse_error() function, which
implements the common error handling code, this function can then be
called from all the different yyerror functions.
The benefit of this is that (in a future commit) I can improve the
error output, and all the expression parsers will benefit.
This commit is pure refactoring though, and so, there should be no
user visible changes after this commit.
Approved-By: John Baldwin <jhb@FreeBSD.org>
While working on a later commit in this series I realised that the
error() function doesn't support output styling. Due to the way that
output from error() calls is passed around within the exception
object and often combined with other output, it's not immediately
obvious to me if we should be trying to support styling in this
context or not.
On inspection, I found one place in GDB where we apparently try to
apply styling within the error() output (in procfs.c). I suspect this
error() call might not be tested.
Rather than try to implement styling in the error() output, right now
I'm proposing to just remove the attempt to style error() output.
This doesn't mean that someone shouldn't add error() styling in the
future, but right now, I'm not planning to do that, I just wanted to
fix this in passing.
Approved-By: John Baldwin <jhb@FreeBSD.org>
Suppose we want to use la.got to generate 32 pcrel and
32 abs instruction sequences respectively. According to
the existing conditions, to generate 32 pcrel sequences
use -mabi=ilp32*, and to generate 32 abs use -mabi=ilp32*
and -mla-global-with-abs.
Due to the fact that the conditions for generating 32 abs
also satisfy 32 pcrel, using -mabi=ilp32* and -mla-global-with-abs
will result in only generating instruction sequences of 32 pcrel.
By modifying the conditions for macro expansion and adjusting
the matching order of macro instructions, it is ensured that
the correct sequence of instructions can be generated.
The common igen code was forked from the ppc long ago. The filter
module is still pretty similar in API, so we can unfork them with
a little bit of effort.
The filter.c module is still here because of the unique it_is API.
The common igen code doesn't seem to have an equiv API as this only
operates on two strings and not an actual filter object, and it's
easy enough to leave behind to unfork the rest.
The common igen code was forked from the ppc long ago. The lf module
is still pretty similar in API, so we can unfork them with a little
bit of effort.
Some of the generated ppc code is now slightly different, but that's
because of fixes the common igen code has gained, but not the ppc igen
code (e.g. fixing of #line numbers).
The ppc code retains lf_print__c_code because the common igen code
rewrote the logic to a new table.c API. Let's delay that in the ppc
code to at least unfork all this code.
Add standard multiple inclusion protection, and add a few missing
local includes when one header uses another. This isn't complete,
but fixes some short comings seen when merging the ppc igen.
The common sim-endian is a forked & updated version of the ppc code.
Fortunately, they didn't diverge from the basic APIs, so they are
still compatible, which means we can just delete the ppc version now
that the build env is merged at the top-level.
This is a bit redundant for most ports as they go through sim-basics.h
which always includes sim-types.h before including sim-endian.h, but in
order to unify ppc's sim-endian code, we need this include here. Plus,
it's the directly we generally want to go to get away from one header
that defines all APIs and causes hard to untangle dependencies.
The common/ code has macros with the same name but different behavior:
it's for declaring integer constants as 64-bit, not for casting them.
Rename ppc's local variant since it's only used in this file in order
to avoid conflicts.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. It adds some overhead, so it's not great, but it shouldn't
be a big deal. This will go away once compilation is hoisted up.
Currently GDB when executing in reverse over multiple statements in a single
line of source code, GDB stops in the middle of the line. Thus requiring
multiple commands to reach the previous line. GDB should stop at the first
instruction of the line, not in the middle of the line.
The following description of the incorrect behavior was taken from an
earlier message by Pedro Alves <pedro@palves.net>:
https://sourceware.org/pipermail/gdb-patches/2023-January/196110.html
---------------------------------
The source line looks like:
func1 (); func2 ();
in the test case:
(gdb) list 1
1 void func1 ()
2 {
3 }
4
5 void func2 ()
6 {
7 }
8
9 int main ()
10 {
11 func1 (); func2 ();
12 }
compiled with:
$ gcc reverse.c -o reverse -g3 -O0
$ gcc -v
...
gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
Now let's debug it with target record, using current gdb git master
(f3d8ae90b2),
$ gdb ~/reverse
GNU gdb (GDB) 14.0.50.20230124-git
...
Reading symbols from /home/pedro/reverse...
(gdb) start
Temporary breakpoint 1 at 0x1147: file reverse.c, line 11.
Starting program: /home/pedro/reverse
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, main () at reverse.c:11
11 func1 (); func2 ();
(gdb) record
(gdb) disassemble /s
Dump of assembler code for function main:
reverse.c:
10 {
0x000055555555513f <+0>: endbr64
0x0000555555555143 <+4>: push %rbp
0x0000555555555144 <+5>: mov %rsp,%rbp
11 func1 (); func2 ();
=> 0x0000555555555147 <+8>: mov $0x0,%eax
0x000055555555514c <+13>: call 0x555555555129 <func1>
0x0000555555555151 <+18>: mov $0x0,%eax
0x0000555555555156 <+23>: call 0x555555555134 <func2>
0x000055555555515b <+28>: mov $0x0,%eax
12 }
0x0000555555555160 <+33>: pop %rbp
0x0000555555555161 <+34>: ret
End of assembler dump.
(gdb) n
12 }
So far so good, a "next" stepped over the whole of line 11 and stopped at
line 12.
Let's confirm where we are now:
(gdb) disassemble /s
Dump of assembler code for function main:
reverse.c:
10 {
0x000055555555513f <+0>: endbr64
0x0000555555555143 <+4>: push %rbp
0x0000555555555144 <+5>: mov %rsp,%rbp
11 func1 (); func2 ();
0x0000555555555147 <+8>: mov $0x0,%eax
0x000055555555514c <+13>: call 0x555555555129 <func1>
0x0000555555555151 <+18>: mov $0x0,%eax
0x0000555555555156 <+23>: call 0x555555555134 <func2>
0x000055555555515b <+28>: mov $0x0,%eax
12 }
=> 0x0000555555555160 <+33>: pop %rbp
0x0000555555555161 <+34>: ret
End of assembler dump.
Good, we're at the first instruction of line 12.
Now let's undo the "next", with "reverse-next":
(gdb) reverse-next
11 func1 (); func2 ();
Seemingly stopped at line 11. Let's see exactly where:
(gdb) disassemble /s
Dump of assembler code for function main:
reverse.c:
10 {
0x000055555555513f <+0>: endbr64
0x0000555555555143 <+4>: push %rbp
0x0000555555555144 <+5>: mov %rsp,%rbp
11 func1 (); func2 ();
0x0000555555555147 <+8>: mov $0x0,%eax
0x000055555555514c <+13>: call 0x555555555129 <func1>
=> 0x0000555555555151 <+18>: mov $0x0,%eax
0x0000555555555156 <+23>: call 0x555555555134 <func2>
0x000055555555515b <+28>: mov $0x0,%eax
12 }
0x0000555555555160 <+33>: pop %rbp
0x0000555555555161 <+34>: ret
End of assembler dump.
(gdb)
And lo, we stopped in the middle of line 11! That is a bug, we should have
stepped back all the way to the beginning of the line. The "reverse-next"
should have fully undone the prior "next" command.
--------------------
This patch fixes the incorrect GDB behavior by ensuring that GDB stops at
the first instruction in the line.
The test case gdb.reverse/func-map-to-same-line.exp is added to testsuite
to verify this fix when the line table information is and is not available.
When running GDB's testsuite on aarch64-linux/Ubuntu 20.04 (also spotted on
the ppc backend), there are failures in gdb.reverse/solib-precsave.exp and
gdb.reverse/solib-reverse.exp.
The failure happens around the following code:
38 b[1] = shr2(17); /* middle part two */
40 b[0] = 6; b[1] = 9; /* generic statement, end part two */
42 shr1 ("message 1\n"); /* shr1 one */
Normal execution:
- step from line 38 will land on line 40.
- step from line 40 will land on line 42.
Reverse execution:
- step from line 42 will land on line 40.
- step from line 40 will land on line 40.
- step from line 40 will land on line 38.
The problem here is that line 40 contains two contiguous but distinct
PC ranges in the line table, like so:
Line 40 - [0x7ec ~ 0x7f4]
Line 40 - [0x7f4 ~ 0x7fc]
The two distinct ranges are generated because GCC started outputting source
column information, which GDB doesn't take into account at the moment.
When stepping forward from line 40, we skip both of these ranges and land on
line 42. When stepping backward from line 42, we stop at the start PC of the
second (or first, going backwards) range of line 40.
Since we've reached ecs->event_thread->control.step_range_start, we stop
stepping backwards.
The above issues were fixed by introducing a new function that looks for
adjacent PC ranges for the same line, until we notice a line change. Then
we take that as the start PC of the range. The new start PC for the range
is used for the control.step_range_start when setting up a step range.
The test case gdb.reverse/map-to-same-line.exp is added to test the fix
for the above reverse step issues.
Patch has been tested on PowerPC, X86 and AArch64 with no regressions.
This patch adds two new options to gdb_compile to specify if the compile
should or should not generate the line table information. The
options are supported on clang and gcc version 7 and newer.
Patch has been tested on PowerPC with both gcc and clang.
This commit adds a mechanism for GDB to detect the linetable opcode
DW_LNS_set_epilogue_begin. This opcode is set by compilers to indicate
that a certain instruction marks the point where the frame is destroyed.
While the standard allows for multiple points marked with epilogue_begin
in the same function, for performance reasons, the function that
searches for the epilogue address will only find the last address that
sets this flag for a given block.
This commit also changes amd64_stack_frame_destroyed_p_1 to attempt to
use the epilogue begin directly, and only if an epilogue can't be found
will it attempt heuristics based on the current instruction.
Finally, this commit also changes the dwarf assembler to be able to emit
epilogue-begin instructions, to make it easier to test this patch
Approved-By: Tom Tromey <tom@tromey.com>
Now that the ppc configure script is just namespaced options, we can
move it to ppc/acinclude.m4 and include it directly in the top-level
configure script and kill off the last subdir configure script.
Switch from ad-hoc $silent checks & echo calls to standard
AC_MSG_CHECKING & AC_MSG_RESULT calls. Also delete pointless
variable setting after calling AC_MSG_ERROR.
Now that the ppc script only checks configure options and sets up
variables in the Makefile from those, delete all the compile related
logic to greatly simplify the configure script.
While the sim code doesn't utilize HAVE_LONG_LONG itself, other code
(like libiberty) seem to, so check for it in the top-level for all
ports to leverage.
Move the stub logic to the device files themselves. This makes the
configure & build logic more static which will make it easier to move
to the top-level build, and matches what we did with the common/ hw
tree already.
This also decouples the logic from the two -- in the past, you needed
both sem & shm in order to enable the device models, but now each one
is tied to its own independent knob. Practically speaking, this will
probably not make a difference, but it simplifies the build a bit.
Instead of executing code to see if SysV semaphores & shared memory
are available, switch to just a compile-time test. The system used
to compile might not match the system used to run the code wrt the
current kernel & OS settings, but the library APIs should. So move
the failures from compile-time to runtime so the program is more
portable, and works correctly even when cross-compiling.
