2
0
mirror of https://sourceware.org/git/binutils-gdb.git synced 2025-02-17 13:10:12 +08:00
Commit Graph

109193 Commits

Author SHA1 Message Date
H.J. Lu
30a954525f i386: Allow GOT32 relocations against ABS symbols
GOT32 relocations are allowed since absolute value + addend is stored in
the GOT slot.

Tested on glibc 2.35 build with GCC 11.2 and -Os.

bfd/

	PR ld/28870
	* elfxx-x86.c (_bfd_elf_x86_valid_reloc_p): Also allow GOT32
	relocations.

ld/

	PR ld/28870
	* testsuite/ld-i386/i386.exp: Run pr28870.
	* testsuite/ld-i386/pr28870.d: New file.
	* testsuite/ld-i386/pr28870.s: Likewise.
2022-02-07 16:04:10 -08:00
GDB Administrator
a194bde670 Automatic date update in version.in 2022-02-08 00:00:21 +00:00
Andrew Burgess
0642912e83 gdb/python: allow Value.format_string to return styled output
Add a new argument to the gdb.Value.format_string method, 'styling'.
This argument is False by default.

When this argument is True, then the returned string can contain output
styling escape sequences.

When this argument is False, then the returned string will not contain
any styling escape sequences.

If the returned string is going to be printed to the user, then it is
often nice to retain the GDB styling.

For the testing, we need to adjust the TERM environment variable, as
we do for all the styling tests.  I'm now running all of the C tests
in gdb.python/py-format-string.exp in an environment where styling
could be generated, but only my new test should actually produce
styled output, hopefully this will catch the case where a bug might
cause format_string to always produce styled output.
2022-02-07 16:52:47 +00:00
Lancelot SIX
573269a87c gdb: make thread_info::m_thread_fsm a std::unique_ptr
While working on function calls, I realized that the thread_fsm member
of struct thread_info is a raw pointer to a resource it owns.  This
commit changes the type of the thread_fsm member to a std::unique_ptr in
order to signify this ownership relationship and slightly ease resource
management (no need to manually call delete).

To ensure consistent use, the field is made a private member
(m_thread_fsm).  The setter method (set_thread_fsm) can then check
that it is incorrect to associate a FSM to a thread_info object if
another one is already in place.  This is ensured by an assertion.

The function run_inferior_call takes an argument as a pointer to a
call_thread_fsm and installs it in it in a thread_info instance.  Also
change this function's signature to accept a unique_ptr in order to
signify that the ownership of the call_thread_fsm is transferred during
the call.

No user visible change expected after this commit.

Tested on x86_64-linux with no regression observed.

Change-Id: Ia1224f72a4afa247801ce6650ce82f90224a9ae8
2022-02-07 06:12:06 -05:00
Andrew Burgess
d08cbc5d32 gdb: unbuffer all input streams when not using readline
This commit should fix PR gdb/28711.  What's actually going on is
pretty involved, and there's still a bit of the story that I don't
understand completely, however, from my observed results, I think that
the change I propose making here (or something very similar) is going
to be needed.

The original bug report involves using eclipse to drive gdb using mi
commands.  A separate tty is spun off in which to send gdb the mi
commands, this tty is created using the new-ui command.

The behaviour observed is that, given a particular set of mi commands
being sent to gdb, we sometimes see an ESPIPE error from a lseek
call, which ultimately results in gdb terminating.

The problems all originate from gdb_readline_no_editing_callback in
gdb/event-top.c, where we can (sometimes) perform calls to fgetc, and
allow glibc to perform buffering on the FILE object being used.

I say sometime, because, gdb_readline_no_editing_callback already
includes a call to disable the glibc buffering, but this is only done
if the input stream is not a tty.  In our case the input stream is a
tty, so the buffering is left in place.

The first step to understanding why this problem occurs is to
understand that eclipse sends multiple commands to gdb very quickly
without waiting for and answer to each command, eclipse plans to
collect all of the command results after sending all the commands to
gdb.  In fact, eclipse sends the commands to gdb that they appear to
arrive in the gdb process as a single block of data.  When reproducing
this issue within the testsuite I find it necessary to send multiple
commands using a single write call.

The next bit of the story gets a little involved, and this is where my
understanding is not complete.  I can describe the behaviour that I
observe, and (for me at least) I'm happy that what I'm seeing, if a
little strange, is consistent.  In order to fully understand what's
going on I think I would likely need to dive into kernel code, which
currently seems unnecessary given that I'm happy with the solution I'm
proposing.

The following description all relates to input from a tty in which I'm
not using readline.  I see the same problems either when using a
new-ui tty, or with gdb's standard, non-readline, mi tty.

Here's what I observe happening when I send multiple commands to gdb
using a single write, if I send gdb this:

  command_1\ncommand_2\ncommand_3

then gdb's event loop will wake up (from its select) as it sees there
is input available.  We call into gdb_readline_no_editing_callback,
where we call fgetc, glibc will do a single big read, and get back
just:

  command_1\n

that is, despite there being multiple lines of input available, I
consistently get just a single line.  From glibc a single character is
returned from the fgetc call, and within gdb we accumulate characters,
one at a time, into our own buffer.  Eventually gdb sees the '\n'
character, and dispatches the whole 'command_1' into gdb's command
handler, which processes the command and prints the result.  We then
return to gdb_readline_no_editing_callback, which in turn returns to
gdb's event loop where we re-enter the select.

Inside the select we immediately see that there is more input waiting
on the input stream, drop out of the select, and call back into
gdb_readline_no_editing_callback.  In this function we again call
fgetc where glibc performs another big read.  This time glibc gets:

  command_2\n

that is, we once again get just a single line, despite there being a
third line available.  Just like the first command we copy the whole
string, character by character into gdb's buffer, then handle the
command.  After handling the command we go to the event loop, enter,
and then exit the select, and call back to the function
gdb_readline_no_editing_callback.

In gdb_readline_no_editing_callback we again call fgetc, this time
glibc gets the string:

  command_3\n

like before, we copy this to gdb's buffer and handle the command, then
we return to the event loop.  At this point the select blocks while we
wait for more input to arrive.

The important bit of this is that someone, somewhere is, it appears,
taking care to split the incoming write into lines.

My next experiment is to try something like:

  this_is_a_very_long_command\nshort_command\n

However, I actually make 'this_is_a_very_long_command' very long, as
in many hundreds of characters long.  One way to do this is:

  echo xxxxxx.....xxxxx

and just adding more and more 'x' characters as needed.  What I'm
aiming for is to have the first command be longer than glibc's
internal read buffer, which, on my machine, is 1024 characters.

However, for this discussion, lets imagine that glibc's buffer is just
8 characters (we can create just this situation by adding a suitable
setbuf call into gdb_readline_no_editing_callback).

Now, if I send gdb this data:

  abcdefghij\nkl\n

The first read from glibc will get 'abcdefgh', that is a full 8
character buffer.  Once gdb has copied these to its buffer we call
fgetc again, and now glibc will get 'ij\n', that is, just like before,
multiple lines are split at the '\n' character.  The full command,
which is now in gdb's buffer can be handled 'abcdefghij', after which
we go (via the event loop) back to gdb_readline_no_editing_callback.
Now we call fgetc, and glibc will get 'kl\n', which is then handled in
the normal way.

So far, so good.  However, there is, apparently, one edge case where
the above rules don't apply.

If the '\n' character is the first character read from the kernel,
then the incoming lines are not split up.  So, given glibc's 8
character buffer, if I send gdb this:

  abcdefgh\nkl\n

that is the first command is 8 characters plus a newline, then, on the
first read (from within glibc) we get 'abcdefgh' in a single buffer.
As there's no newline gdb calls fgetc again, and glibc does another
large read, now we get:

  \nkl\n

which doesn't follow the above pattern - the lines are not split into
separate buffers!

So, gdb reads the first character from glibc using fgetc, this is the
newline.  Now gdb has a complete command, and so the command is
handled.  We then return to the event loop and enter the select.

The problem is that, as far as the kernel is concerned, there is no
more input pending, it's all been read into glibc's buffer, and so the
select doesn't return.  The second command is basically stuck in
glibc's buffer.

If I send another command to gdb, or even just send an empty
command (a lone newline) then the select returns, we call into
gdb_readline_no_editing_callback, and now gdb sees the second
command.

OK, so the above is interesting, but it doesn't explain the ESPIPE
error.

Well, that's a slightly different, but related issue.  The ESPIPE
case will _only_ show up when using new-ui to create the separate tty
for mi commands, and is a consequence of this commit:

  commit afe09f0b63
  Date:   Thu Jul 18 17:20:04 2019 +0100

      Fix for using named pipes on Windows

Prior to this commit, the new-ui command would open the tty three
times, once each for stdin, stderr, and stdout.  After this commit we
open the tty just once and reuse the FILE object for all three roles.

Consider the problem case, where glibc has (unexpectedly) read the
second command into its internal buffer.  When we handle the first
command we usually end up having to write something to the mi output
stream.

After the above commit the same FILE object represents both the input
and output streams, so, when gdb tries to write to the FILE object,
glibc spots that there is input pending within the input buffer, and
so assumes that we have read ahead of where we should be in the input
file.  To correct for this glibc tries to do an lseek call to
reposition the file offset of the output stream prior to writing to
it.  However, as the output stream is a tty, and seeking is not
supported on a tty, this lseek call fails, this results in the ESPIPE,
which ultimately causes gdb to terminate.

So, now we understand why the ESPIPE triggers (which was what caused
the gdb crash in the original bug report), and we also understand that
sometime gdb will not handle the second command in a timely
fashion (if the first command is just the wrong length). So, what to
do about all this?

We could revert the commit mentioned above (and implement its
functionality another way).  This would certainly resolve the ESPIPE
issue, the buffered input would now only be on the input stream, the
output stream would have no buffered input, and so glibc would never
try to lseek, and so we'd never get the ESPIPE error.

However, this only solves one of the two problems.  We would still
suffer from the problem where, if the first command is just the wrong
length, the second command will not (immediately) get handled.

The only solution I can see to this problem is to unbuffer the input
stream.  If glibc is not buffering the input, but instead, we read
incoming data character by character from the kernel, then everything
will be fine.  As soon as we see the newline at the end of the first
command we will handle the first command.  As glibc will have no
buffered input it will not be tempted to lseek, so no ESPIPE error.
When we go have to the event loop there will be more data pending in
the kernel, so the select will immediately return, and the second
command will be processed.

I'm tempted to suggest that we should move the unbuffering of the
input stream out of gdb_readline_no_editing_callback and do it
somewhere earlier, more like when we create the input streams.
However, I've not done that in this commit for a couple of reasons:

  1. By keeping the unbuffering in gdb_readline_no_editing_callback
  I'm making the smallest possible change that fixes the bug.  Moving
  the unbuffering somewhere better can be done as a refactor later, if
  that 's felt to be important,

  2. I don't think making repeated calls to unbuffer the input will
  have that much performance impact.  We only make the unbuffer call
  once per call to gdb_readline_no_editing_callback, and, if the input
  stream is already unbuffered we'll return pretty quickly, so I don't
  see this as being massively costly,

  3. Tom is currently doing lots of gdb stream management changes and
  I want to minimise the chances we'll conflict.

So, this commit just changes gdb_readline_no_editing_callback to
always unbuffer the input stream.

The test for this issue sends two commands in a loop, with the first
command growing bigger each time around the loop.  I actually make the
first command bigger by just adding whitespace to the front, as gdb
still has to read the complete command (including whitespace) via
glibc, so this is enough to trigger the bug.

The original bug was reported when using a virtual machine, and in
this situation we see this in the strace output:

  read(9, "70-var-info-path-expression var1.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", 1024) = 64
  read(9, "\n71-var-info-path-expression var1.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n", 1024) = 67

I'm not completely sure what's going on here, but it appears that the
kernel on the virtual machine is delivering the input to glibc slower
than I see on my real hardware; glibc asks for 1024 bytes, but only
gets 64 bytes the first time.  In the second read we see the problem
case, the first character is the newline, but then the entire second
command is included.

If I run this exact example on my real hardware then the first command
would not be truncated at 64 bytes, instead, I'd expect to see the
newline included in the first read, with the second command split into
a second read.

So, for testing, I check cases where the first command is just a few
characters (starting at 8 character), all the way up to 2048
characters.  Hopefully, this should mean we hit the problem case for
most machine setups.

The only last question relates to commit afe09f0b63 that I
mentioned earlier.  That commit was intended to provide support for
Microsoft named pipes:

  https://docs.microsoft.com/en-us/windows/win32/ipc/named-pipes

I know next to nothing about this topic beyond a brief scan of the
above link, but I think these windows named pipe are closer in
behaviour to unix sockets than to unix named fifos.

I am a little nervous that, after the above commit, we now use the
same FILE for in, err, and out streams.  In contrast, in a vanilla C
program, I would expect different FILE objects for each stream.

Still, I'm reluctant to revert the above commit (and provide the same
functionality a different way) without a specific bug to point at,
and, now that the streams are unbuffered, I expect a lot of the read
and write calls are going straight to the kernel with minimal glibc
involvement, so maybe it doesn't really matter.  Anyway, I haven't
touched the above patch, but it is something to keep in mind when
working in this area.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28711
2022-02-07 10:24:27 +00:00
Andrew Burgess
59091b1280 gdb/disasm: combine the no printing disassembler setup code
We have three places in gdb where we initialise a disassembler that
will not print anything (used for figuring out the length of
instructions, or collecting other information from the disassembler).

Each of these places has its own stub function to act as a print like
callback, the stub function is identical in each case, and just does
nothing.

In this commit I create a new function to initialise a disassembler
that doesn't print anything, and have all three locations use this new
function.  There's now only one non-printing stub function.

There should be no user visible changes after this commit.
2022-02-07 09:59:16 +00:00
Tankut Baris Aktemur
61fb73769a gdb: add the 'set/show suppress-cli-notifications' command
GDB already has a flag to suppress printing notification events, such
as thread and inferior context switches, on the CLI.  This is used
internally when executing commands.  Make the flag available to the
user via a new command.  This is expected to be useful in scripts.

For instance, suppose that when Inferior 1 gets to a certain state,
you want to add and set up a new inferior using the commands below,
but you also want to have a reduced/clean output.

  define do-setup
    printf "Setting up Inferior 2...\n"
    add-inferior -exec a.out
    inferior 2
    break file.c:3
    run
    inferior 1
    printf "Done\n"
  end

Currently, GDB prints

  (gdb) do-setup
  Setting up Inferior 2...
  [New inferior 2]
  Added inferior 2 on connection 1 (native)
  [Switching to inferior 2 [<null>] (/tmp/a.out)]
  Breakpoint 2 at 0x1155: file file.c, line 3.

  Thread 2.1 "a.out" hit Breakpoint 2, main () at file.c:3
  3         return 0;
  [Switching to inferior 1 [process 7670] (/tmp/test)]
  [Switching to thread 1.1 (process 7670)]
    main () at test.c:2
  2         int a = 1;
  Done

GDB's Python API make it possible to capture and return GDB's output,
but this does not work for all the streams.  In particular, CLI
notification events are not captured:

  (gdb) python gdb.execute("do-setup", False, True)
  [Switching to inferior 2 [<null>] (/tmp/a.out)]

  Thread 2.1 "a.out" hit Breakpoint 2, main () at file.c:3
  3         return 0;
  [Switching to inferior 1 [process 8263] (/tmp/test)]
  [Switching to thread 1.1 (process 8263)]
    main () at test.c:2
  2         int a = 1;

You can use the new "set suppress-cli-notifications" command to
suppress the output:

  (gdb) set suppress-cli-notifications on
  (gdb) do-setup
  Setting up Inferior 2...
  [New inferior 2]
  Added inferior 2 on connection 1 (native)
  Breakpoint 2 at 0x1155: file file.c, line 3.
  Done
2022-02-07 08:26:56 +01:00
Tankut Baris Aktemur
2b826f7592 gdb/cli: add a 'normal_stop' option to 'cli_suppress_notification'
Extend the 'cli_suppress_notification' struct with a new field,
'normal_stop', that can be used for checking if printing normal stop
events on the CLI should be suppressed.

This patch only introduces the flag.  The subsequent patch adds a user
command to turn the flag off/on.
2022-02-07 08:26:56 +01:00
Tankut Baris Aktemur
f36c891801 gdb/cli: convert cli_suppress_notification from int to bool
Convert the suppress_notification flag for the CLI from int to bool.
2022-02-07 08:26:55 +01:00
Alan Modra
6a9d08661b Revert "elf: Remove the 1-page gap before the RELRO segment"
This reverts commit 2f83249c13.

	PR ld/28743
	* ldlang.c (lang_size_relro_segment_1): Revert 2022-01-10 changes.
	* testsuite/ld-i386/pr20830.d: Likewise.
	* testsuite/ld-s390/gotreloc_64-relro-1.dd: Likewise.
	* testsuite/ld-x86-64/pr14207.d: Likewise.
	* testsuite/ld-x86-64/pr18176.d: Likewise.
	* testsuite/ld-x86-64/pr20830a-now.d: Likewise.
	* testsuite/ld-x86-64/pr20830a.d: Likewise.
	* testsuite/ld-x86-64/pr20830b-now.d: Likewise.
	* testsuite/ld-x86-64/pr20830b.d: Likewise.
	* testsuite/ld-x86-64/pr21038a-now.d: Likewise.
	* testsuite/ld-x86-64/pr21038a.d: Likewise.
	* testsuite/ld-x86-64/pr21038b-now.d: Likewise.
	* testsuite/ld-x86-64/pr21038c-now.d: Likewise.
	* testsuite/ld-x86-64/pr21038c.d: Likewise.
2022-02-07 13:42:41 +10:30
Alan Modra
5197c88e2a Revert "ld: Rewrite lang_size_relro_segment_1"
This reverts commit c804c6f98d.

	PR ld/28743
	PR ld/28819
	* ldlang.c (lang_size_relro_segment_1): Revert 2022-01-14 change.
	* testsuite/ld-x86-64/pr28743-1.d: Likewise.
	* testsuite/ld-x86-64/pr28743-1.s: Likewise.
	* testsuite/ld-x86-64/x86-64.exp: Likewise.
2022-02-07 13:42:41 +10:30
GDB Administrator
2b1026f391 Automatic date update in version.in 2022-02-07 00:00:13 +00:00
Alan Modra
a03c7c40b7 A more elegant pr28827-1 testcase
Use .irpc macros in pr28827-1.s

	* testsuite/ld-powerpc/pr28827-1.s: Make the testcase more
	elegant.  Comment.
2022-02-07 09:36:19 +10:30
Tom Tromey
1a1bfce78f Merge do_val_print and common_val_print
The only caller of do_val_print just does a small bit of work before
the call.  This patch merges the two functions, and removes an
unnecessary local variable, making gdb a bit simpler.
2022-02-06 14:27:58 -07:00
Simon Marchi
5d0027b9ba gdb: remove SYMBOL_LINE macro
Add a getter and a setter for a symbol's line.  Remove the corresponding macro
and adjust all callers.

Change-Id: I229f2b8fcf938c07975f641361313a8761fad9a5
2022-02-06 16:03:47 -05:00
Simon Marchi
5f9c5a63ce gdb: remove SYMBOL_TYPE macro
Add a getter and a setter for a symbol's type.  Remove the corresponding
macro and adjust all callers.

Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de
2022-02-06 16:03:47 -05:00
Simon Marchi
f5abd8f234 gdb: remote SYMBOL_IS_CPLUS_TEMPLATE_FUNCTION macro
Add a getter for a whether a symbol is a C++ template function.  Remove
the corresponding macro and adjust all callers.

Change-Id: I89abc2802a952b77b0e0eb73a25c2306cb8e8bcc
2022-02-06 16:03:46 -05:00
Simon Marchi
32177d6e39 gdb: remove SYMBOL_INLINED macro
Add a getter and a setter for whether a symbol is inlined.  Remove the
corresponding macro and adjust all callers.

Change-Id: I934468da3b5a32dd6b161a6f252a6b1b94737279
2022-02-06 16:03:46 -05:00
Simon Marchi
d9743061f9 gdb: remove SYMBOL_IS_ARGUMENT macro
Add a getter and a setter for whether a symbol is an argument.  Remove
the corresponding macro and adjust all callers.

Change-Id: I71b4f0465f3dfd2ed8b9e140bd3f7d5eb8d9ee81
2022-02-06 16:03:46 -05:00
Simon Marchi
7b3ecc7555 gdb: remove SYMBOL_OBJFILE_OWNED macro
Add a getter and a setter for whether a symbol is objfile owned.  Remove
the corresponding macro and adjust all callers.

Change-Id: Ib7ef3718d65553ae924ca04c3fd478b0f4f3147c
2022-02-06 16:03:46 -05:00
Simon Marchi
6c9c307c67 gdb: remove SYMBOL_DOMAIN macro
Add a getter and a setter for a symbol's domain.  Remove the
corresponding macro and adjust all callers.

Change-Id: I54465b50ac89739c663859a726aef8cdc6e4b8f3
2022-02-06 16:03:46 -05:00
Simon Marchi
66d7f48f80 gdb: remove SYMBOL_CLASS macro, add getter
Change-Id: I83211d5a47efc0564386e5b5ea4a29c00b1fd46a
2022-02-06 16:03:46 -05:00
Simon Marchi
d1eebf9a6f gdb: remove SYMBOL_IMPL macro, add method
Add a getter for a symbol's "impl".  Remove the corresponding macro and
adjust all callers.

Change-Id: Ibe26ed442f0f99a0f5cddafca30bd96ec7fb9fa8
2022-02-06 16:03:46 -05:00
Simon Marchi
ba44b1a3e0 gdb: remove SYMBOL_ACLASS_INDEX macro, add getter/setter
Add a getter and a setter for a symbol's aclass index.  Remove the
corresponding macro and adjust all callers.

Change-Id: Ie8c8d732624cfadb714aba5ddafa3d29409b3d39
2022-02-06 16:03:46 -05:00
Simon Marchi
81e32b6a84 gdb: remove SYMBOL_MATCHES_SEARCH_NAME
It seems like this macro is not needed at all anymore, it just wraps the
function of the same name with the same arguments.

Change-Id: I3c342ac8d89c27af5aee1a819dc32cc6396fd41b
2022-02-06 16:03:46 -05:00
Simon Marchi
3574a7b3f1 gdb: remove SYMTAB_DIRNAME macro
Remove the macro, replace with an equivalent method.

Change-Id: I46ec36b91bb734331138eb9cd086b2db01635aed
2022-02-06 16:03:46 -05:00
Simon Marchi
cdc22ffbf5 gdb: remove SYMTAB_PSPACE macro
Remove the macro, replace with an equivalent method.

Change-Id: Icccc20e7e8ae03ac4dac1c7514c25a12a9a0ac69
2022-02-06 16:03:46 -05:00
Simon Marchi
652099717d gdb: remove SYMTAB_OBJFILE macro
Remove the macro, replace with an equivalent method.

Change-Id: I8f9ecd290ad28502e53c1ceca5006ba78bf042eb
2022-02-06 16:03:46 -05:00
Simon Marchi
012cfab919 gdb: remove SYMTAB_BLOCKVECTOR macro
Remove the macro, replace with an equivalent method.

Change-Id: Id6fe2a79c04bcd6c69ccaefb7a69bc06a476288c
2022-02-06 16:03:46 -05:00
Simon Marchi
1ee2e9f930 gdb: remove SYMTAB_LANGUAGE macro, add getter/setter
Add a getter and a setter for a symtab's language.  Remove the
corresponding macro and adjust all callers.

Change-Id: I9f4d840b11c19f80f39bac1bce020fdd1739e11f
2022-02-06 16:03:44 -05:00
Simon Marchi
5b6074611e gdb: remove SYMTAB_LINETABLE macro, add getter/setter
Add a getter and a setter for a symtab's linetable.  Remove the
corresponding macro and adjust all callers.

Change-Id: I159183fc0ccd8e18ab937b3c2f09ef2244ec6e9c
2022-02-06 15:48:19 -05:00
Simon Marchi
c615965258 gdb: remove SYMTAB_COMPUNIT macro, add getter/setter
Add a getter and a setter for a symtab's compunit_symtab.  Remove the
corresponding macro and adjust all callers.

For brevity, I chose the name "compunit" instead of "compunit_symtab"
the the field, getter and setter names.  Since we are already in symtab
context, the _symtab suffix seems redundant.

Change-Id: I4b9b731c96e3594f7733e75af1e3d01bc0e4fe92
2022-02-06 15:48:19 -05:00
Simon Marchi
10cc645b6a gdb: remove COMPUNIT_MACRO_TABLE macro, add getter/setter
Add a getter and a setter for a compunit_symtab's macro table.  Remove the
corresponding macro and adjust all callers.

Change-Id: I00615ea72d5ac43d9a865e941cb2de0a979c173a
2022-02-06 15:48:19 -05:00
Simon Marchi
3908b699f8 gdb: remove COMPUNIT_EPILOGUE_UNWIND_VALID macro, add getter/setter
Add a getter and a setter for a compunit_symtab's epilogue unwind valid flag.
Remove the corresponding macro and adjust all callers.

Change-Id: If3b68629d987767da9be7041a95d96dc34367a9a
2022-02-06 15:48:19 -05:00
Simon Marchi
b0fc0e82d5 gdb: remove COMPUNIT_LOCATIONS_VALID macro, add getter/setter
Add a getter and a setter for a compunit_symtab's locations valid flag.
Remove the corresponding macro and adjust all callers.

Change-Id: I3e3cfba926ce62993d5b61814331bb3244afad01
2022-02-06 15:48:19 -05:00
Simon Marchi
c1e35bc9c6 gdb: remove COMPUNIT_BLOCK_LINE_SECTION macro, add getter/setter
Add a getter and a setter for a compunit_symtab's block line section.  Remove
the corresponding macro and adjust all callers.

Change-Id: I3eb1a323388ad55eae8bfa45f5bc4a08dc3df455
2022-02-06 15:48:19 -05:00
Simon Marchi
af39c5c874 gdb: remove COMPUNIT_BLOCKVECTOR macro, add getter/setter
Add a getter and a setter for a compunit_symtab's blockvector.  Remove
the corresponding macro and adjust all callers.

Change-Id: I99484c6619dcbbea7c5d89c72aa660316ca62f64
2022-02-06 15:48:18 -05:00
Simon Marchi
0d9acb4531 gdb: remove COMPUNIT_DIRNAME macro, add getter/setter
Add a getter and a setter for a compunit_symtab's dirname.  Remove the
corresponding macro and adjust all callers.

Change-Id: If2f39b295fd26822586485e04a8b8b5aa5cc9b2e
2022-02-06 15:48:18 -05:00
Simon Marchi
ab5f850eed gdb: remove COMPUNIT_PRODUCER macro, add getter/setter
Add a getter and a setter for a compunit_symtab's producer.  Remove the
corresponding macro and adjust all callers.

Change-Id: Ia1d6d8a0e247a08a21af23819d71e49b37d8931b
2022-02-06 15:48:18 -05:00
Simon Marchi
422f1ea279 gdb: remove COMPUNIT_DEBUGFORMAT macro, add getter/setter
Add a getter and a setter for a compunit_symtab's debugformat.  Remove
the corresponding macro and adjust all callers.

Change-Id: I1667b02d5322346f8e23abd9f8a584afbcd75975
2022-02-06 15:48:18 -05:00
Simon Marchi
510860f278 gdb: remove COMPUNIT_FILETABS macro
I think that most remaining uses of COMPUNIT_FILETABS intend to get the
primary filetab of the compunit_symtab specifically (and not to iterate
over all filetabs, for example, those cases would use compunit_filetabs,
which has been converted to compunit_symtab::filetabs), so replace mosts
uses with compunit_symtab::primary_filetab.

In jit.c, function finalize_symtab, we can save the symtab object
returned by allocate_symtab and use it, it makes things simpler.

Change-Id: I4e51d6d4b40759de8768b61292e5e13c8eae2e38
2022-02-06 15:48:18 -05:00
Simon Marchi
102cc23543 gdb: move compunit_filetabs to compunit_symtab::filetabs
Make compunit_filetabs, used to iterate a compunit_symtab's filetabs, a
method of compunit_symtab.  The name filetabs conflicts with the current
name of the field.  Rename the field to m_filetabs, since at this point
nothing outside of compunit_symtab uses it, so we should treat it as
private (even though it's not actually private).  Rename the
last_filetab field to m_last_filetab as well (it's only used on
compunit_symtab::add_filetab).

Adjust the COMPUNIT_FILETABS macro to keep its current behavior of
returning the first filetab.

Change-Id: I537b553a44451c52d24b18ee1bfa47e23747cfc3
2022-02-06 15:48:18 -05:00
Simon Marchi
36664835fa gdb: add compunit_symtab::set_primary_filetab method
Add a method to set the primary filetab of the CU.  This is currently
done in buildsym_compunit::end_symtab_with_blockvector.

Change-Id: I16c51a6b90a4cb4c0c5f183b0f2e12bc64b6fd74
2022-02-06 15:48:18 -05:00
Simon Marchi
43b49762a1 gdb: add compunit_symtab::add_filetab method
Add a method to append a filetab/symtab to a compunit_symtab.  There is
a single place where this is done currently, in allocate_symtab.

Change-Id: Ie86c6e34d175728173d1cffdce44acd6cff6c31d
2022-02-06 15:48:18 -05:00
Simon Marchi
0b17a4f78f gdb: rename compunit_primary_filetab to compunit_symtab::primary_filetab
Make compunit_primary_filetab a method of compunit_symtab.

Change-Id: Iee3c4f7e36d579bf763c5bba146e5e10d6766768
2022-02-06 15:48:18 -05:00
Simon Marchi
9821f3fa56 gdb: remove COMPUNIT_OBJFILE macro
Remove the macro, update all users to use the getter directly.

Change-Id: I3f0fd6f4455d1c4ebd5da73b561eb18a979ef1f6
2022-02-06 15:48:18 -05:00
Simon Marchi
f1f58f102e gdb: add getter/setter for compunit_symtab::objfile
Rename the field to m_objfile, and add a getter and a setter.  Update
all users.

Change-Id: If7e2f763ee3e70570140d9af9261b1b056253317
2022-02-06 15:48:18 -05:00
Tom Tromey
a723766c0e Allow non-ASCII characters in Rust identifiers
Rust 1.53 (quite a while ago now) ungated the support for non-ASCII
identifiers.  This didn't work in gdb.  This is PR rust/20166.

This patch fixes the problem by allowing non-ASCII characters to be
considered as identifier components.  It seemed simplest to just pass
them through -- doing any extra checking didn't seem worthwhile.

The new test also verifies that such characters are allowed in strings
and character literals as well.  The latter also required a bit of
work in the lexer.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20166
2022-02-06 13:24:25 -07:00
Tom Tromey
c1f5e54825 Fix Rust parser bug with function fields
In Rust, 'obj.f()' is a method call -- but '(obj.f)()' is a call of a
function-valued field 'f' in 'obj'.  The Rust parser in gdb currently
gets this wrong.  This is PR rust/24082.

The expression and Rust parser rewrites made this simple to fix --
simply wrapping a parenthesized expression in a new operation handles
it.  This patch has a slight hack because I didn't want to introduce a
new exp_opcode enumeration constant just for this.  IMO this doesn't
matter, since we should work toward removing dependencies on these
opcodes anyway; but let me know what you think of this.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24082
2022-02-06 13:13:31 -07:00
H.J. Lu
a92613915e ld: Add emultempl/emulation.em
Add emultempl/emulation.em to define ld_${EMULATION_NAME}_emulation so
that new emulation hooks can be added easily.

	* emultempl/aix.em (LDEMUL_AFTER_OPEN): New.
	(LDEMUL_SET_OUTPUT_ARCH): Likewise.
	(LDEMUL_CHOOSE_TARGET): Likewise.
	(LDEMUL_BEFORE_ALLOCATION): Likewise.
	(LDEMUL_CREATE_OUTPUT_SECTION_STATEMENTS): Likewise.
	(LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise.
	(LDEMUL_PARSE_ARGS): Likewise.
	(LDEMUL_ADD_OPTIONS): Likewise.
	(LDEMUL_HANDLE_OPTION): Likewise.
	(LDEMUL_UNRECOGNIZED_FILE): Likewise.
	(LDEMUL_PRINT_SYMBOL): Likewise.
	(ld_${EMULATION_NAME}_emulation): Removed.
	Source ${srcdir}/emultempl/emulation.em.
	* emultempl/beos.em (gld_${EMULATION_NAME}_before_parse):
	Renamed to ...
	(gld${EMULATION_NAME}_before_parse): This.
	(gld_${EMULATION_NAME}_set_symbols): Renamed to ...
	(gld${EMULATION_NAME}_set_symbols): This.
	(gld_${EMULATION_NAME}_after_open): Renamed to ...
	(gld${EMULATION_NAME}_after_open): This.
	(gld_${EMULATION_NAME}_before_allocation): Renamed to ...
	(gld${EMULATION_NAME}_before_allocation): This.
	(gld_${EMULATION_NAME}_get_script): Renamed to ...
	(gld${EMULATION_NAME}_get_script): This.
	(LDEMUL_AFTER_OPEN): New.
	(LDEMUL_BEFORE_ALLOCATION): Likewise.
	(LDEMUL_PLACE_ORPHAN): Likewise.
	(LDEMUL_SET_SYMBOLS): Likewise.
	(LDEMUL_ADD_OPTIONS): Likewise.
	(LDEMUL_HANDLE_OPTION): Likewise.
	(ld_${EMULATION_NAME}_emulation): Removed.
	Source ${srcdir}/emultempl/emulation.em.
	* emultempl/elf.em (LDEMUL_AFTER_PARSE): New.
	(LDEMUL_AFTER_OPEN): Likewise.
	(LDEMUL_BEFORE_PLACE_ORPHANS): Likewise.
	(LDEMUL_AFTER_ALLOCATION): Likewise.
	(LDEMUL_SET_OUTPUT_ARCH): Likewise.
	(LDEMUL_BEFORE_ALLOCATION): Likewise.
	(LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise.
	(LDEMUL_PLACE_ORPHAN): Likewise.
	(LDEMUL_ADD_OPTIONS): Likewise.
	(LDEMUL_HANDLE_OPTION): Likewise.
	(LDEMUL_LIST_OPTIONS): Likewise.
	(LDEMUL_UNRECOGNIZED_FILE): Likewise.
	(ld_${EMULATION_NAME}_emulation): Removed.
	Source ${srcdir}/emultempl/emulation.em.
	* emultempl/emulation.em: New file.
	* emultempl/generic.em (ld_${EMULATION_NAME}_emulation): Removed.
	Source ${srcdir}/emultempl/emulation.em.
	* emultempl/msp430.em (LDEMUL_AFTER_OPEN): New.
	(LDEMUL_AFTER_ALLOCATION): Likewise.
	(LDEMUL_PLACE_ORPHAN): Likewise.
	(LDEMUL_FINISH): Likewise.
	(LDEMUL_ADD_OPTIONS): Likewise.
	(LDEMUL_HANDLE_OPTION): Likewise.
	(LDEMUL_LIST_OPTIONS): Likewise.
	(ld_${EMULATION_NAME}_emulation): Removed.
	Source ${srcdir}/emultempl/emulation.em.
	* emultempl/pe.em (gld_${EMULATION_NAME}_before_parse): Renamed
	to ...
	(gld${EMULATION_NAME}_before_parse): This.
	(gld_${EMULATION_NAME}_list_options): Renamed to ...
	(gld${EMULATION_NAME}_list_options): This.
	(gld_${EMULATION_NAME}_set_symbols): Renamed to ...
	(gld${EMULATION_NAME}_set_symbols): This.
	(gld_${EMULATION_NAME}_after_parse): Renamed to ...
	(gld${EMULATION_NAME}_after_parse): This.
	(gld_${EMULATION_NAME}_after_open): Renamed to ...
	(gld${EMULATION_NAME}_after_open): This.
	(gld_${EMULATION_NAME}_before_allocation): Renamed to ...
	(gld${EMULATION_NAME}_before_allocation): This.
	(gld_${EMULATION_NAME}_unrecognized_file): Renamed to ...
	(gld${EMULATION_NAME}_unrecognized_file): This.
	(gld_${EMULATION_NAME}_recognized_file): Renamed to ...
	(gld${EMULATION_NAME}_recognized_file): This.
	(gld_${EMULATION_NAME}_finish): Renamed to ...
	(gld${EMULATION_NAME}_finish): This.
	(gld_${EMULATION_NAME}_place_orphan): Renamed to ...
	(gld${EMULATION_NAME}_place_orphan): This.
	(gld_${EMULATION_NAME}_open_dynamic_archive): Renamed to ...
	(gld${EMULATION_NAME}_open_dynamic_archive): This.
	(gld_${EMULATION_NAME}_find_potential_libraries): Renamed to ...
	(gld${EMULATION_NAME}_find_potential_libraries): This.
	(gld_${EMULATION_NAME}_get_script): Renamed to ...
	(gld${EMULATION_NAME}_get_script): This.
	(LDEMUL_AFTER_PARSE): New.
	(LDEMUL_AFTER_OPEN): Likewise.
	(LDEMUL_BEFORE_ALLOCATION): Likewise.
	(LDEMUL_FINISH=): Likewise.
	(LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise.
	(LDEMUL_PLACE_ORPHAN): Likewise.
	(LDEMUL_SET_SYMBOLS): Likewise.
	(LDEMUL_ADD_OPTIONS): Likewise.
	(LDEMUL_HANDLE_OPTION): Likewise.
	(LDEMUL_UNRECOGNIZED_FILE): Likewise.
	(LDEMUL_LIST_OPTIONS): Likewise.
	(LDEMUL_RECOGNIZED_FILE): Likewise.
	(LDEMUL_FIND_POTENTIAL_LIBRARIES): Likewise.
	(ld_${EMULATION_NAME}_emulation): Removed.
	Source ${srcdir}/emultempl/emulation.em.
	* emultempl/pep.em (gld_${EMULATION_NAME}_before_parse): Renamed
	to ...
	(gld${EMULATION_NAME}_before_parse): This.
	(gld_${EMULATION_NAME}_list_options): Renamed to ...
	(gld${EMULATION_NAME}_list_options): This.
	(gld_${EMULATION_NAME}_set_symbols): Renamed to ...
	(gld${EMULATION_NAME}_set_symbols): This.
	(gld_${EMULATION_NAME}_after_parse): Renamed to ...
	(gld${EMULATION_NAME}_after_parse): This.
	(gld_${EMULATION_NAME}_after_open): Renamed to ...
	(gld${EMULATION_NAME}_after_open): This.
	(gld_${EMULATION_NAME}_before_allocation): Renamed to ...
	(gld${EMULATION_NAME}_before_allocation): This.
	(gld_${EMULATION_NAME}_unrecognized_file): Renamed to ...
	(gld${EMULATION_NAME}_unrecognized_file): This.
	(gld_${EMULATION_NAME}_recognized_file): Renamed to ...
	(gld${EMULATION_NAME}_recognized_file): This.
	(gld_${EMULATION_NAME}_finish): Renamed to ...
	(gld${EMULATION_NAME}_finish): This.
	(gld_${EMULATION_NAME}_place_orphan): Renamed to ...
	(gld${EMULATION_NAME}_place_orphan): This.
	(gld_${EMULATION_NAME}_open_dynamic_archive): Renamed to ...
	(gld${EMULATION_NAME}_open_dynamic_archive): This.
	(gld_${EMULATION_NAME}_find_potential_libraries): Renamed to ...
	(gld${EMULATION_NAME}_find_potential_libraries): This.
	(gld_${EMULATION_NAME}_get_script): Renamed to ...
	(gld${EMULATION_NAME}_get_script): This.
	(LDEMUL_AFTER_PARSE): New.
	(LDEMUL_AFTER_OPEN): Likewise.
	(LDEMUL_BEFORE_ALLOCATION): Likewise.
	(LDEMUL_FINISH=): Likewise.
	(LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise.
	(LDEMUL_PLACE_ORPHAN): Likewise.
	(LDEMUL_SET_SYMBOLS): Likewise.
	(LDEMUL_ADD_OPTIONS): Likewise.
	(LDEMUL_HANDLE_OPTION): Likewise.
	(LDEMUL_UNRECOGNIZED_FILE): Likewise.
	(LDEMUL_LIST_OPTIONS): Likewise.
	(LDEMUL_RECOGNIZED_FILE): Likewise.
	(LDEMUL_FIND_POTENTIAL_LIBRARIES): Likewise.
	(ld_${EMULATION_NAME}_emulation): Removed.
	Source ${srcdir}/emultempl/emulation.em.
	* emultempl/ticoff.em (gld_${EMULATION_NAME}_list_options):
	Renamed to ...
	(gld${EMULATION_NAME}_list_options): This.
	(gld_${EMULATION_NAME}_before_parse): Renamed to ...
	(gld_${EMULATION_NAME}_get_script): Renamed to ...
	(gld${EMULATION_NAME}_get_script): This.
	(LDEMUL_ADD_OPTIONS): New.
	(LDEMUL_HANDLE_OPTION): Likewise.
	(LDEMUL_LIST_OPTIONS): Likewise.
	(ld_${EMULATION_NAME}_emulation): Removed.
	Source ${srcdir}/emultempl/emulation.em.
	* emultempl/vanilla.em (LDEMUL_BEFORE_PARSE): New.
	(LDEMUL_SET_OUTPUT_ARCH): Likewise.
	(LDEMUL_GET_SCRIPT): Likewise.
	(EMULATION_NAME): Likewise.
	(OUTPUT_FORMAT): Likewise.
	(ld_vanilla_emulation): Removed.
	Source ${srcdir}/emultempl/emulation.em.
2022-02-06 06:25:41 -08:00