bfd/doc/chew.c extracts documentation from source code comments
annotated with keywords, and generates much of bfd.h and libbfd.h from
those same comments. The docs have suffered from people (me too)
adding things like CODE_FRAGMENT to the source to put code into bfd.h
without realising that CODE_FRAGMENT also puts @example around said
code into the docs. So we have random senseless things in the docs.
This patch fixes that problem (well, the senseless things from
CODE_FRAGMENT), moves most of the code out of bfd-in.h, and improves a
few chew.c features. libbfd.h now automatically gets ATTRIBUTE_HIDDEN
prototypes, and indentation in bfd.h and libbfd.h is better.
These functions don't belong in opncls.c.
* libbfd-in.h (bfd_release): Delete prototype.
* opncls.c (bfd_alloc, bfd_zalloc, bfd_release): Move to..
* libbfd.c: ..here. Include objalloc.c and provide bfd_release
with a FUNCTION comment.
* bfd-in2.h: Regenerate.
* libbfd.h: Regenerate.
bfd_elf_bfd_from_remote_memory is just a wrapper, and the function
could be implemented for other formats. Move it to opncls.c because
it acts a little like some of the other bfd_open* routines. Also give
it the usual FUNCTION etc. comment so prototypes and docs are handled
automatically.
* elf.c (bfd_elf_bfd_from_remote_memory): Move to..
* opncls.c: ..here, add FUNCTION comment.
* bfd-in.h (bfd_elf_bfd_from_remote_memory): Delete prototype.
* bfd-in2.h: Regenerate.
* hash.c (higher_prime_number): Use uint32_t param, return value,
tables and variables.
(bfd_default_hash_table_size): Make it an unsigned int.
(bfd_hash_set_default_size): Use unsigned int param and return.
* bfd-in.h (bfd_hash_set_default_size): Update prototype.
* bfd-in2.h: Regenerate.
The crc calculated is 32 bits. Replace uses of unsigned long with
uint32_t. Also use bfd_byte* for buffers.
bfd/
* opncls.c (bfd_calc_gnu_debuglink_crc32): Use stdint types.
(bfd_get_debug_link_info_1, bfd_get_debug_link_info): Likewise.
(separate_debug_file_exists, bfd_follow_gnu_debuglink): Likewise.
(bfd_fill_in_gnu_debuglink_section): Likewise.
* bfd-in2.h: Regenerate.
gdb/
* auto-load.c (auto_load_objfile_script): Update type of
bfd_get_debug_link_info argument.
* symfile.c (find_separate_debug_file_by_debuglink): Likewise.
* gdb_bfd.c (get_file_crc): Update type of
bfd_calc_gnu_debuglink_crc32 argument.
This explains exactly why the high reloc adjustment is as it is,
replacing the rather nebulous existing comment. I've also changed the
expression from (lo+0x8000)&0xffff to (lo&0xffff)^0x8000 which better
matches part of the standard 16-bit sign extension (resulting in
exactly the same value), and hoisted the calculation out of the loop.
* elfxx-mips.c (_bfd_mips_elf_lo16_reloc): Expand vallo
comment. Hoist calculation out of loop.
Initialize wpoffset_to_wpnumto avoid TCL error which happens in some aarch64 types.
ERROR: in testcase /root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp
ERROR: can't read "wpoffset_to_wpnum(1)": no such element in array
ERROR: tcl error code TCL READ VARNAME
ERROR: tcl error info:
can't read "wpoffset_to_wpnum(1)": no such element in array
while executing
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30340
Reviewed-by: Luis Machado <luis.machado@arm.com>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
GCC 13 points out that main_subfile has local function scope, but a
pointer to it is assigned to the global inclTable array subfile
element field:
In function ‘void process_linenos(CORE_ADDR, CORE_ADDR)’,
inlined from ‘void aix_process_linenos(objfile*)’ at xcoffread.c:727:19,
inlined from ‘void aix_process_linenos(objfile*)’ at xcoffread.c:720:1:
xcoffread.c:629:37: error: storing the address of local variable ‘main_subfile’ in ‘*inclTable.19_45 + _28._inclTable::subfile’ [-Werror=dangling-pointer=]
629 | inclTable[ii].subfile = &main_subfile;
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
xcoffread.c: In function ‘void aix_process_linenos(objfile*)’:
xcoffread.c:579:18: note: ‘main_subfile’ declared here
579 | struct subfile main_subfile;
| ^~~~~~~~~~~~
xcoffread.c:496:19: note: ‘inclTable’ declared here
496 | static InclTable *inclTable; /* global include table */
| ^~~~~~~~~
Fix this by making main_subfile file static. And allocate and
deallocated together with inclTable in allocate_include_entry and
xcoff_symfile_finish. Adjust the use of main_subfile in
process_linenos to take a pointer to the subfile.
In gdb.dwarf2/dw2-abs-hi-pc.exp we do:
...
set sources [lmap i $sources { expr { "$srcdir/$subdir/$i" } }]
...
The use of expr is not idiomatic. Fix this by using set instead:
...
set sources [lmap i $sources { set tmp $srcdir/$subdir/$i }]
...
Reported-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Andreas Schwab <schwab@suse.de>
In AIX if there is a main and a thread created from it , then once the
program completed execution and goes to pd_disable () inferior_ptid
had pid 0 leading to an assertion failure while finding the thread's data
in aix-thread.c file.
This patch is a fix for the same.
error_stream is trivial and only used in a couple of spots in
breakpoint.c. This patch removes it in favor of just writing it out
at the spots where it was used.
Noticed in passing that the prepare_for_testing call in
gdb.linespec/cp-completion-aliases.exp does not pass the 'c++' flag,
despite this being a C++ test.
I guess, as the source file has the '.cc' extension, all the compilers
are doing the right thing anyway -- the source file uses templates, so
is definitely being compiled as C++.
I noticed this when I tried to set CXX_FOR_TARGET (but not
CC_FOR_TARGET) and spotted that this script was still using the C
compiler.
Fixed in this commit by adding the 'c++' flag for prepare_for_testing.
The Debugger Adapter Protocol defines a "launch" request but leaves
the parameters up to the implementation:
Since launching is debugger/runtime specific, the arguments for
this request are not part of this specification.
This patch adds some documentation for the parameter GDB currently
defines. Note that I plan to add more parameters here, and perhaps
there will be other extensions in time as well.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
I don't think that having struct ui_interp_info separated from struct ui
is very useful. As of today, it looks like an unnecessary indirection
layer. Move the contents of ui_interp_info directly into struct ui, and
update all users.
Change-Id: I817ba6e047dbcc4ba15b666af184b40bfed7e521
I'd like to move some things so they become methods on struct ui. But
first, I think that struct ui and the related things are big enough to
deserve their own file, instead of being scattered through top.{c,h} and
event-top.c.
Change-Id: I15594269ace61fd76ef80a7b58f51ff3ab6979bc
This changes field_is_static to be a method on struct field, and
updates all the callers. Most of this patch was written by script.
Regression tested on x86-64 Fedora 36.
With TERM=ansi, when resizing a TUI window from LINES/COLUMNS 31/118
(maximized) to 20/78 (de-maximized), I get a garbled screen (that ^L doesn't
fix) and a message:
...
@@ resize done 0, size = 77x20
...
with the resulting width being 77 instead of the expected 78.
[ The discrepancy also manifests in CLI, filed as PR30346. ]
The discrepancy comes from tui_resize_all, where we ask readline for the
screen size:
...
rl_get_screen_size (&screenheight, &screenwidth);
...
As it happens, when TERM is set to ansi, readline decides that the terminal
cannot auto-wrap lines, and reserves one column to deal with that, and as a
result reports back one less than the actual screen width:
...
$ echo $COLUMNS
78
$ TERM=xterm gdb -ex "show width" -ex q
Number of characters gdb thinks are in a line is 78.
$ TERM=ansi gdb -ex "show width" -ex q
Number of characters gdb thinks are in a line is 77.
...
In tui_resize_all, we need the actual screen width, and using a screenwidth of
one less than the actual value garbles the screen.
This is currently not causing trouble in testing because we have a workaround
in place in proc Term::resize. If we disable the workaround:
...
- stty columns [expr {$_cols + 1}] < $::gdb_tty_name
+ stty columns $_cols < $::gdb_tty_name
...
and dump the screen we get the same type of screen garbling:
...
0 +---------------------------------------+|
1 ||
2 ||
3 ||
...
Another way to reproduce the problem is using command "maint info screen".
After starting gdb with TERM=ansi, entering TUI, and issuing the command, we
get:
...
Number of characters curses thinks are in a line is 78.
...
and after maximizing and demaximizing the window we get:
...
Number of characters curses thinks are in a line is 77.
...
If we use TERM=xterm, we do get the expected 78.
Fix this by:
- detecting when readline will report back less than the actual screen width,
- accordingly setting a new variable readline_hidden_cols,
- using readline_hidden_cols in tui_resize_all to fix the resize problem, and
- removing the workaround in Term::resize.
The test-case gdb.tui/empty.exp serves as regression test.
I've applied the same fix in tui_async_resize_screen, the new test-case
gdb.tui/resize-2.exp serves as a regression test for that change. Without
that fix, we have:
...
FAIL: gdb.tui/resize-2.exp: again: gdb width 80
...
Tested on x86_64-linux.
PR tui/30337
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30337
When doing a build which uses stub-termcap, we run into:
...
(gdb) set width 7
<b) FAIL: gdb.base/readline.exp: set width 7 (timeout)
...
Since readline can't detect very basic terminal support, it falls back on
horizontal scrolling.
Fix this by detecting the horizontal scrolling case, and skipping the
subsequent test.
Tested on x86_64-linux.
PR testsuite/30400
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30400
Latest libc++[1] causes transitive include to <locale> when
<mutex> or <thread> header is included. This causes
gdb to not build[2] since <locale> defines isupper/islower etc.
functions that are explicitly macroed-out in safe-ctype.h to
prevent their use.
Use the suggestion from libc++ to include <locale> internally when
building in C++ mode to avoid build errors.
Use safe-gdb-ctype.h as the include instead of "safe-ctype.h"
to keep this isolated to gdb since rest of binutils
does not seem to use much C++.
[1]: https://reviews.llvm.org/D144331
[2]: https://issuetracker.google.com/issues/277967395
Test-case gdb.ada/excep_handle.exp fails since commit e2f620135d
("gdb/testsuite: change newline patterns used in gdb_test"):
...
(gdb) continue^M
Continuing.^M
^M
Catchpoint 2, exception at 0x00000000004020b6 in foo () at foo.adb:26^M
26 when Constraint_Error =>^M
(gdb) FAIL: gdb.ada/excep_handle.exp: continuing to first Constraint_Error \
exception handlers
...
The output is supposed to be matched by:
...
gdb_test "continue" \
"Continuing\.$eol$catchpoint_constraint_error_msg$eol.*" \
"continuing to first Constraint_Error exception handlers"
...
but the $eol bit no longer matches due to the stricter matching introduced
in aforementioned commit.
Fix this by dropping the "$eol.*" bit.
Tested on x86_64-linux.
PR testsuite/30399
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30399
With a build without ncurses we run into:
...
src/gdb/utils.c: In function ‘void maintenance_info_screen(const char*, int)’:
src/gdb/utils.c:1310:7: error: ‘COLS’ was not declared in this scope
COLS);
^~~~
src/gdb/utils.c:1331:8: error: ‘LINES’ was not declared in this scope
LINES);
^~~~~
...
Fix this by using HAVE_LIBCURSES.
Tested on x86_64-linux.
PR build/30391
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30391
With a build with --disable-tui, we get:
...
(gdb) PASS: gdb.tui/main.exp: set interactive-mode off
maint set tui-left-margin-verbose on^M
Undefined maintenance set command: "tui-left-margin-verbose on". \
Try "help maintenance set".^M
(gdb) FAIL: gdb.tui/main.exp: maint set tui-left-margin-verbose on
...
Fix this by adding the missing "require allow_tui_tests".
Tested on x86_64-linux.
I noticed the following behaviour:
$ gdb -q -i=mi /tmp/hello.x
=thread-group-added,id="i1"
=cmd-param-changed,param="print pretty",value="on"
~"Reading symbols from /tmp/hello.x...\n"
(gdb)
-break-insert -p 99 main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000401198",func="main",file="/tmp/hello.c",fullname="/tmp/hello.c",line="18",thread-groups=["i1"],thread="99",times="0",original-location="main"}
(gdb)
info breakpoints
&"info breakpoints\n"
~"Num Type Disp Enb Address What\n"
~"1 breakpoint keep y 0x0000000000401198 in main at /tmp/hello.c:18\n"
&"../../src/gdb/thread.c:1434: internal-error: print_thread_id: Assertion `thr != nullptr' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable."
&"\n"
&"----- Backtrace -----\n"
&"Backtrace unavailable\n"
&"---------------------\n"
&"\nThis is a bug, please report it."
&" For instructions, see:\n"
&"<https://www.gnu.org/software/gdb/bugs/>.\n\n"
Aborted (core dumped)
What we see here is that when using the MI a user can create
thread-specific breakpoints for non-existent threads. Then if we try
to use the CLI 'info breakpoints' command GDB throws an assertion.
The assert is a result of the print_thread_id call when trying to
build the 'stop only in thread xx.yy' line; print_thread_id requires a
valid thread_info pointer, which we can't have for a non-existent
thread.
In contrast, when using the CLI we see this behaviour:
$ gdb -q /tmp/hello.x
Reading symbols from /tmp/hello.x...
(gdb) break main thread 99
Unknown thread 99.
(gdb)
The CLI doesn't allow a breakpoint to be created for a non-existent
thread. So the 'info breakpoints' command is always fine.
Interestingly, the MI -break-info command doesn't crash, this is
because the MI uses global thread-ids, and so never calls
print_thread_id. However, GDB does support using CLI and MI in
parallel, so we need to solve this problem.
One option would be to change the CLI behaviour to allow printing
breakpoints for non-existent threads. This would preserve the current
MI behaviour.
The other option is to pull the MI into line with the CLI and prevent
breakpoints being created for non-existent threads. This is good for
consistency, but is a breaking change for the MI.
In the end I figured that it was probably better to retain the
consistent CLI behaviour, and just made the MI reject requests to
place a breakpoint on a non-existent thread. The only test we had
that depended on the old behaviour was
gdb.mi/mi-thread-specific-bp.exp, which was added by me in commit:
commit 2fd9a436c8
Date: Fri Feb 17 10:48:06 2023 +0000
gdb: don't duplicate 'thread' field in MI breakpoint output
I certainly didn't intend for this test to rely on this feature of the
MI, so I propose to update this test to only create breakpoints for
threads that exist.
Actually, I've added a new test that checks the MI rejects creating a
breakpoint for a non-existent thread, and I've also extended the test
to run with the separate MI/CLI UIs, and then tested 'info
breakpoints' to ensure this command doesn't crash.
I've extended the documentation of the `-p` flag to explain the
constraints better.
I have also added a NEWS entry just in case someone runs into this
issue, at least then they'll know this change in behaviour was
intentional.
One thing that I did wonder about while writing this patch, is whether
we should treat requests like this, on both the MI and CLI, as another
form of pending breakpoint, something like:
(gdb) break foo thread 9
Thread 9 does not exist.
Make breakpoint pending on future thread creation? (y or [n]) y
Breakpoint 1 (foo thread 9) pending.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> foo thread 9
Don't know if folk think that would be a useful idea or not? Either
way, I think that would be a separate patch from this one.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
The deprecated_show_value_hack function is now only used inside
cli-setshow.c, so lets make the function static to discourage its use
anywhere else.
There should be no user visible changes after this commit
Reviewed-By: Tom Tromey <tom@tromey.com>
Like the previous two commits, this commit fixes set/show inferior-tty
to work with $_gdb_setting_str.
Instead of using a scratch variable which is then pushed into the
current inferior from a set callback, move to the API that allows for
getters and setters, and store the value directly within the current
inferior.
Update an existing test to check the inferior-tty setting.
Reviewed-By: Tom Tromey <tom@tromey.com>
The previous commit fixed set/show args when used with
$_gdb_setting_str, this commit fixes set/show cwd.
Instead of using a scratch variable which is then pushed into the
current inferior from a set callback, move to the API that allows for
getters and setters, and store the value directly within the current
inferior.
Update the existing test to check the cwd setting.
I noticed that $_gdb_setting_str was not working with 'args', e.g.:
$ gdb -q --args /tmp/hello.x arg1 arg2 arg3
Reading symbols from /tmp/hello.x...
(gdb) show args
Argument list to give program being debugged when it is started is "arg1 arg2 arg3".
(gdb) print $_gdb_setting_str("args")
$1 = ""
This is because the 'args' setting is implemented using a scratch
variable ('inferior_args_scratch') which is updated when the user does
'set args ...'. There is then a function 'set_args_command' which is
responsible for copying the scratch area into the current inferior.
However, when the user sets the arguments via the command line the
scratch variable is not updated, instead the arguments are pushed
straight into the current inferior.
There is a second problem, when the current inferior changes the
scratch area is not updated, which means that the value returned will
only ever reflect the last call to 'set args ...' regardless of which
inferior is currently selected.
Luckily, the fix is pretty easy, set/show variables have an
alternative API which requires we provide some getter and setter
functions. With this done the scratch variable can be removed and the
value returned will now always reflect the current inferior.
While working on set/show args I also rewrote show_args_command to
remove the use of deprecated_show_value_hack.
Reviewed-By: Tom Tromey <tom@tromey.com>
In infcmd.c, in order to add command completion to some of the 'set'
commands, we are currently creating the command, then looking up the
command by calling lookup_cmd.
This is no longer necessary, we already return the relevant
cmd_list_element object when the set/show command is created, and we
can use that to set the command completion callback.
I don't know if there's actually any tests for completion of these
commands, but I manually checked, and each command still appears to
offer the expected filename completion.
There should be no user visible changes after this commit.
Reviewed-By: Tom Tromey <tom@tromey.com>
I see these failures, when running with the native-gdbserver of
native-extended-gdbserver boards:
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.reverse/finish-reverse-next.exp ...
FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 LEP from function body
FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 5, from function body
FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 GEP call from function body
FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 50 from function body
Let's use this simpler program to illustrate the problem:
int main()
{
int a = 362;
a = a * 17;
return a;
}
It compiles down to:
int a = 362;
401689: c7 45 fc 6a 01 00 00 movl $0x16a,-0x4(%rbp)
a = a * 17;
401690: 8b 55 fc mov -0x4(%rbp),%edx
401693: 89 d0 mov %edx,%eax
401695: c1 e0 04 shl $0x4,%eax
401698: 01 d0 add %edx,%eax
40169a: 89 45 fc mov %eax,-0x4(%rbp)
return a;
40169d: 8b 45 fc mov -0x4(%rbp),%eax
When single stepping these lines, debugging locally, while recording,
these are the recorded instructions (basically one for each instruction
shown above):
(gdb) maintenance print record-instruction 0
4 bytes of memory at address 0x00007fffffffdc5c changed from: 6a 01 00 00
Register rip changed: (void (*)()) 0x40169a <main+21>
(gdb) maintenance print record-instruction -1
Register rax changed: 5792
Register eflags changed: [ PF AF IF ]
Register rip changed: (void (*)()) 0x401698 <main+19>
(gdb) maintenance print record-instruction -2
Register rax changed: 362
Register eflags changed: [ PF ZF IF ]
Register rip changed: (void (*)()) 0x401695 <main+16>
(gdb) maintenance print record-instruction -3
Register rax changed: 4200069
Register rip changed: (void (*)()) 0x401693 <main+14>
(gdb) maintenance print record-instruction -4
Register rdx changed: 140737488346696
Register rip changed: (void (*)()) 0x401690 <main+11>
(gdb) maintenance print record-instruction -5
4 bytes of memory at address 0x00007fffffffdc5c changed from: 00 00 00 00
Register rip changed: (void (*)()) 0x401689 <main+4>
(gdb) maintenance print record-instruction -6
Not enough recorded history
But when debugging remotely:
(gdb) maintenance print record-instruction 0
Register rdx changed: 140737488346728
Register rip changed: (void (*)()) 0x401690 <main+11>
(gdb) maintenance print record-instruction -1
4 bytes of memory at address 0x00007fffffffdc7c changed from: 00 00 00 00
Register rip changed: (void (*)()) 0x401689 <main+4>
(gdb) maintenance print record-instruction -2
Not enough recorded history
In this list, we only have entries for the beginning of each line. This
is because of the remote target's support for range stepping. The
record-full layer can only record instructions when the underlying
process target reports a stop. With range stepping, the remote target
single-steps multiple instructions at a time, so the record-full target
doesn't get to see and record them all.
Fix this by making the record-full layer disable range-stepping
before handing the resume request to the beneath layer, forcing the
remote target to report stops for each instruction.
Change-Id: Ia95ea62720bbcd0b6536a904360ffbf839eb823d
PR 13098 explains that if a user attempts to use a string with either
`printf' (or `eval'), gdb returns an error (inferior not running):
(gdb) printf "%s\n", "hello"
evaluation of this expression requires the target program to be active
However, the parser can certainly handle this case:
(gdb) p "hello"
$1 = "hello"
This discrepancy occurs because printf_c_string does not handle
this specific case. The passed-in value that we are attempting to print
as a string is TYPE_CODE_ARRAY but it's lval type is not_lval.
printf_c_string will only attempt to print a string from the value's
contents when !TYPE_CODE_PTR, lval is lval_internalvar, and the value's
type is considered a string type:
if (value->type ()->code () != TYPE_CODE_PTR
&& value->lval () == lval_internalvar
&& c_is_string_type_p (value->type ()))
{
...
}
Otherwise, it attempts to read the value of the string from the target's
memory (which is what actually generates the "evaluation of this ..."
error message).
get_discrete_low_bound has this code:
/* Set unsigned indicator if warranted. */
if (low >= 0)
type->set_is_unsigned (true);
It's bad to modify a type in a getter like this, so this patch removes
this code. FWIW I looked and this code has been there since at least
1999 (it was in the initial sourceware import).
Types in general would benefit from const-ification, which would
probably reveal more code like this, but I haven't attempted that.
Regression tested on x86-64 Fedora 36.
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
Eli pointed out that @var isn't needed in @defun in Texinfo. This
patch removes the cases I found in python.texi. I also renamed some
variables in one spot, because "-" isn't valid in a Python variable
name.
After this commit:
commit e2f620135d
Date: Thu Mar 30 13:26:25 2023 +0100
gdb/testsuite: change newline patterns used in gdb_test
There were some regressions in gdb.trace/*.exp tests when run with the
native-gdbserver board. This commit fixes these regressions.
All the problems are caused by unnecessary trailing newline characters
included in the patterns passed to gdb_test. After the above commit
the testsuite is stricter when matching trailing newlines, and so the
additional trailing newline characters are now causing the test to
fail. Fix by removing all the excess trailing newline characters.
In some cases this cleanup means we should use gdb_test_no_output,
I've done that where appropriate. In a couple of other places I've
made use of multi_line to better build the expected output pattern.
Use run_cc_link_tests for PR ld/26391 tests to compile PR ld/26391 tests
in C.
PR ld/30002
* testsuite/ld-elf/elf.exp: Use run_cc_link_tests for PR ld/26391
tests.
Let --no-relax-gp only disable the gp relaxation for lui and pcrel
relaxations, since x0 base and gp relaxations are different optimizations
in fact, but just use the same function to handle.
bfd/
* elfnn-riscv.c (_bfd_riscv_relax_pc): Like _bfd_riscv_relax_lui,
set gp to zero when --no-relax-gp, then we should still keep the
x0 base relaxation.
(_bfd_riscv_relax_section): Enable _bfd_riscv_relax_pc when
--no-relax-gp, we will disable the gp relaxation in the
_bfd_riscv_relax_pc.
bfd/
*elfnn-riscv.c (_bfd_riscv_relax_lui): For undefined weak symbol,
just relax the R_RISCV_LO12_I/S to R_RISCV_GPREL_I/S, and then don't
update the rs1 to zero until relocate_section.
(_bfd_riscv_relax_pc): Likewise, but for R_RISCV_PCREL_LO12_I/S.
