aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-12-23gdb: on x86-64 non-trivial C++ objects are returned in memoryAndrew Burgess3-4/+57
Fixes PR gdb/28681. It was observed that after using the `finish` command an incorrect value was displayed in some cases. Specifically, this behaviour was observed on an x86-64 target. Consider this test program: struct A { int i; A () { this->i = 0; } A (const A& a) { this->i = a.i; } }; A func (int i) { A a; a.i = i; return a; } int main () { A a = func (3); return a.i; } And this GDB session: $ gdb -q ex.x Reading symbols from ex.x... (gdb) b func Breakpoint 1 at 0x401115: file ex.cc, line 14. (gdb) r Starting program: /home/andrew/tmp/ex.x Breakpoint 1, func (i=3) at ex.cc:14 14 A a; (gdb) finish Run till exit from #0 func (i=3) at ex.cc:14 main () at ex.cc:23 23 return a.i; Value returned is $1 = { i = -19044 } (gdb) p a $2 = { i = 3 } (gdb) Notice how after the `finish` the contents of $1 are junk, but, when I immediately ask for the value of `a`, I get back the correct value. The problem here is that after the finish command GDB calls the function amd64_return_value to figure out where the return value can be found (on x86-64 targets anyway). This function makes the wrong choice for the struct A in our case, as sizeof(A) <= 8, then amd64_return_value decides that A will be returned in a register. GDB then reads the return value register an interprets the contents as an instance of A. Unfortunately, A is not trivially copyable (due to its copy constructor), and the sys-v specification for argument and return value passing, says that any non-trivial C++ object should have space allocated for it by the caller, and the address of this space is passed to the callee as a hidden first argument. The callee should then return the address of this space as the return value. And so, the register that GDB is treating as containing an instance of A, actually contains the address of an instance of A (in this case on the stack), this is why GDB shows the incorrect result. The call stack within GDB for where we actually go wrong is this: amd64_return_value amd64_classify amd64_classify_aggregate And it is in amd64_classify_aggregate that we should be classifying the type as AMD64_MEMORY, instead of as AMD64_INTEGER as we currently do (via a call to amd64_classify_aggregate_field). At the top of amd64_classify_aggregate we already have this logic: if (TYPE_LENGTH (type) > 16 || amd64_has_unaligned_fields (type)) { theclass[0] = theclass[1] = AMD64_MEMORY; return; } Which handles some easy cases where we know a struct will be placed into memory, that is (a) the struct is more than 16-bytes in size, or (b) the struct has any unaligned fields. All we need then, is to add a check here to see if the struct is trivially copyable. If it is not then we know the struct will be passed in memory. I originally structured the code like this: if (TYPE_LENGTH (type) > 16 || amd64_has_unaligned_fields (type) || !language_pass_by_reference (type).trivially_copyable) { theclass[0] = theclass[1] = AMD64_MEMORY; return; } This solved the example from the bug, and my small example above. So then I started adding some more extensive tests to the GDB testsuite, and I ran into a problem. I hit this error: gdbtypes.h:676: internal-error: loc_bitpos: Assertion `m_loc_kind == FIELD_LOC_KIND_BITPOS' failed. This problem is triggered from: amd64_classify_aggregate amd64_has_unaligned_fields field::loc_bitpos Inside the unaligned field check we try to get the bit position of each field. Unfortunately, in some cases the field location is not FIELD_LOC_KIND_BITPOS, but is FIELD_LOC_KIND_DWARF_BLOCK. An example that shows this bug is: struct B { short j; }; struct A : virtual public B { short i; A () { this->i = 0; } A (const A& a) { this->i = a.i; } }; A func (int i) { A a; a.i = i; return a; } int main () { A a = func (3); return a.i; } It is the virtual base class, B, that causes the problem. The base class is represented, within GDB, as a field within A. However, the location type for this field is a DWARF_BLOCK. I spent a little time trying to figure out how to convert the DWARF_BLOCK to a BITPOS, however, I realised that, in this case at least, conversion is not needed. The C++ standard says that a class is not trivially copyable if it has any virtual base classes. And so, in this case, even if I could figure out the BITPOS for the virtual base class fields, I know for sure that I would immediately fail the trivially_copyable check. So, lets just reorder the checks in amd64_classify_aggregate to: if (TYPE_LENGTH (type) > 16 || !language_pass_by_reference (type).trivially_copyable || amd64_has_unaligned_fields (type)) { theclass[0] = theclass[1] = AMD64_MEMORY; return; } Now, if we have a class with virtual bases we will fail quicker, and avoid the unaligned fields check completely. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28681
2021-12-23gdb: make use of SCOPE_EXIT to manage thread executing stateAndrew Burgess2-23/+9
While working on another patch relating to how GDB manages threads executing and resumed state, I spotted the following code in record-btrace.c: executing = tp->executing (); set_executing (proc_target, inferior_ptid, false); id = null_frame_id; try { id = get_frame_id (get_current_frame ()); } catch (const gdb_exception &except) { /* Restore the previous execution state. */ set_executing (proc_target, inferior_ptid, executing); throw; } /* Restore the previous execution state. */ set_executing (proc_target, inferior_ptid, executing); return id; I notice that we only catch the exception so we can call set_executing, and this is the same call to set_executing that we need to perform in the non-exception return path. This would be much cleaner if we could use SCOPE_EXIT to avoid the try/catch, so lets do that. While cleaning this up, I also applied a similar patch to record-full.c, though there's no try/catch in that case, but using SCOPE_EXIT makes the code safe if, in the future, we do start throwing exceptions. There should be no user visible changes after this commit.
2021-12-23Automatic date update in version.inGDB Administrator1-1/+1
2021-12-22gdb/doc: add some index entries relating to mi-async settingAndrew Burgess1-2/+7
I noticed that the mi-async setting was not referenced from the index in any way, this commit tries to rectify that a bit. The @cindex lines I think are not controversial, these same index entries are used elsewhere in the manual for async related topics (see @node Background Execution). The only bit that might be controversial is that I've added a @kindex entry for 'set mi-async' when the command is documented as '-gdb-set mi-async' (with a similar difference for the show/-gdb-show). My reasoning here is that nothing else is indexed under -gdb-set or -gdb-show, and as -gdb-set/-gdb-show are just the MI equivalent for set/show anything that is documented under set/show can be adjusted using -gdb-set/-gdbshow, and so, I've tried to keep the index consistent for mi-async.
2021-12-22gdb: convert 'set debug lin-lwp' to a boolean commandAndrew Burgess1-9/+20
Convert the 'set debug lin-lwp' command to a boolean. Adds a new LINUX_NAT_SCOPED_DEBUG_ENTER_EXIT macro, and makes use of it in one place (linux_nat_target::stop). The manual entry for 'set debug lin-lwp' is already vague about exactly what arguments this command takes, and the description talks about turning debug on and off, so I don't think there's any updates required there. I have updated the doc strings shown when the users enters 'help show debug lin-lwp' or 'help show debug lin-lwp'. The old title lines used to talk about the 'GNU/Linux lwp module', but this debug flag is now used for any native linux target debug, so we now talk about 'GNU/Linux native target'. The body string for this setting has been changed from 'Enables printf debugging output.' to 'When on, print debug messages relating to the GNU/Linux native target.', the old value looks like a cut&paste error to me.
2021-12-22gdb: add threads debugging switchAndrew Burgess5-0/+63
Add new commands: set debug threads on|off show debug threads Prints additional debug information relating to thread creation and deletion. GDB already announces when threads are created of course.... most of the time, but sometimes threads are added silently, in which case this debug message is the only mechanism to see the thread being added. Also, though GDB does announce when a thread exits, it doesn't announce when the thread object is deleted, I've added a debug message for that. Additionally, having message printed through the debug system will cause the messages to be nested to an appropriate depth when other debug sub-systems are turned on (especially things like `infrun` and `lin-lwp`).
2021-12-22RISC-V: Update Scalar Crypto testcases.jiawei18-144/+144
Add opcodes in testcases to make sure every instruction generate right opcode after disassemble. gas/ChangeLog: * testsuite/gas/riscv/k-ext-64.d: Add opcode detect. * testsuite/gas/riscv/k-ext.d: Ditto. * testsuite/gas/riscv/zbkb-32.d: Ditto. * testsuite/gas/riscv/zbkb-64.d: Ditto. * testsuite/gas/riscv/zbkc-32.d: Ditto. * testsuite/gas/riscv/zbkc-64.d: Ditto. * testsuite/gas/riscv/zbkx-32.d: Ditto. * testsuite/gas/riscv/zbkx-64.d: Ditto. * testsuite/gas/riscv/zknd-32.d: Ditto. * testsuite/gas/riscv/zknd-64.d: Ditto. * testsuite/gas/riscv/zkne-32.d: Ditto. * testsuite/gas/riscv/zkne-64.d: Ditto. * testsuite/gas/riscv/zknh-32.d: Ditto. * testsuite/gas/riscv/zknh-64.d: Ditto. * testsuite/gas/riscv/zksed-32.d: Ditto. * testsuite/gas/riscv/zksed-64.d: Ditto. * testsuite/gas/riscv/zksh-32.d: Ditto. * testsuite/gas/riscv/zksh-64.d: Ditto.
2021-12-21gdbarch-components.py: change empty "params" tuples to empty listsSimon Marchi1-8/+8
During review, it was suggested to change the "params" parameter from a tuple to a list, for esthetic reasons. The empty ones are still tuples though, they should probably be changed to be empty lists, for consistency. It does not change anything in the script result. Change-Id: If13c6c527aa167a5ee5b45740e5f1bda1e9517e4
2021-12-22Automatic date update in version.inGDB Administrator1-1/+1
2021-12-21[AArch64] Fix typo in error messagesLuis Machado1-2/+2
Fix mispelling of PROT_ME to PROT_MTE in the error messages.
2021-12-21Obsolete m32c-rtems and m32r-rtemsJoel Sherrill2-3/+3
2020-12-20 Joel Sherrill <joel@rtems.org> bfd/ * config.bfd (m32c-*-rtems*): Remove target. ld/ * configure.tgt (m32c-*-rtems*): Remove target. * configure.tgt (m32r-*-rtems*): Remove target.
2021-12-21x86: -mfence-as-lock-add=yes doesn't work for 16-bit modeJan Beulich1-1/+6
Rather than trying to fix this (which would require making an assumption on the upper half of %esp being zero), simply issue an error. While at it, since the generated code is in conflict with -momit-lock-prefix=yes, issue an error in that case as well.
2021-12-21gas/ELF: avoid below-base ref in obj_elf_parse_section_letters()Jan Beulich1-13/+11
We would better be prepared for 'm' being the first character of the incoming string.
2021-12-21Typo fixes in binutils docAlan Modra1-4/+4
* doc/binutils.texi: Fix typos.
2021-12-21Automatic date update in version.inGDB Administrator1-1/+1
2021-12-20Remove print_spacesTom Tromey6-31/+19
This removes the print_spaces helper function, in favor of using the "*%s" idiom that's already used in many places in gdb. One spot (in symmisc.c) is changed to use print_spaces_filtered, because the rest of that function is using filtered output. (This highlights one way that the printf idiom is better -- this error is harder to make when using that.) Regression tested on x86-64 Fedora 34.
2021-12-20Remove puts_debugTom Tromey2-87/+0
I noticed that puts_debug isn't used in the tree. git log tells me that the last use was removed in 2015: commit 40e0b27177e747600d3ec186458fe0e482a1cf77 Author: Pedro Alves <palves@redhat.com> Date: Mon Aug 24 15:40:26 2015 +0100 Delete the remaining ROM monitor targets ... and this commit mentions that the code being removed here probably hadn't worked for 6 years prior to that. Based on this, I'm removing puts_debug. I don't think it's useful. Tested by rebuilding.
2021-12-20Make n_spaces return a const char *Tom Tromey2-2/+2
n_spaces keeps the spaces in a static buffer. If a caller overwrites these, it may give an incorrect result to a subsequent caller. So, make the return type const to help avoid this outcome.
2021-12-20Add Enze Li to gdb/MAINTAINERSEnze Li1-0/+1
2021-12-20gdb/ada-exp.y: Reformat comment to follow GDB's coding standardsJoel Brobecker1-9/+9
This commit reformats a comment in gdb/ada-exp.y to avoid the leading '*' at the beginning of each line of the comment.
2021-12-20gdb/ada-lang.h: Reformat comment to follow coding standardsJoel Brobecker1-2/+2
This commit reformats a comment in gdb/ada-lang.h to avoid the leading '*' at the beginning of each line of the comment.
2021-12-20Automatic date update in version.inGDB Administrator1-1/+1
2021-12-19Obsolete m32c-rtemsAlan Modra1-0/+1
2021-12-19readelf: avoid a possible divide by zeroAlan Modra1-0/+4
* readelf.c (process_section_headers): Check SHT_RELR entsize.
2021-12-19Automatic date update in version.inGDB Administrator1-1/+1
2021-12-18gdb: add "exit" command as an alias for "quit"Enze Li3-7/+15
This command adds the "exit" command as an alias for the "quit" command, as requested in PR gdb/28406. The documentation is also updated to mention this new command. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28406
2021-12-18gdb: add assert in remote_target::wait relating to async being offAndrew Burgess1-1/+5
While working on another patch I ended up in a situation where I had async mode disabled (with 'maint set target-async off'), but the async event token got marked anyway. In this situation GDB was continually calling into remote_target::wait, however, the async token would never become unmarked as the unmarking is guarded by target_is_async_p. We could just unconditionally unmark the token, but that would feel like just ignoring a bug, so, instead, lets assert that if !target_is_async_p, then the async token should not be marked. This assertion would have caught my earlier mistake. There should be no user visible changes with this commit.
2021-12-18gdb/remote: some fixes for 'maint set target-async off'Andrew Burgess1-104/+84
While working on another patch relating to remote targets, I wanted to test with 'maint set target-async off' in place. Unfortunately I ran into some problems. This commit is an attempt to fix one of the issues I hit. In my particular case I was actually running with: maint set target-async off maint set target-non-stop off that is, we're telling GDB to force the targets to operate in non-async mode, and in all-stop mode. Here's my GDB session showing the problem: (gdb) maintenance set target-async off (gdb) maintenance set target-non-stop off (gdb) target extended-remote :54321 Remote debugging using :54321 (gdb) attach 2365960 Attaching to process 2365960 No unwaited-for children left. (gdb) Notice the 'No unwaited-for children left.' error, this is the problem. There's no reason why GDB should not be able to attach to the process. The problem is this: 1. The user runs 'attach PID' and this sends GDB into attach_command in infcmd.c. From here we call the ::attach method on the attach target, which will be the extended_remote_target. 2. In extended_remote_target::attach, we attach to the remote target and get the first reply (which is a stop packet). We put off processing the stop packet until the end of ::attach. We setup the inferior and thread to represent the process we attached to, and download the target description. Finally, we process the initial stop packet. If '!target_is_non_stop_p ()' and '!target_can_async_p ()', which is the case for us given the maintenance commands we used, we cache the stop packet within the remote_state::buf for later processing. 3. Back in attach_command, if 'target_is_non_stop_p ()' then we request that the target stops. This will either process any cached stop replies, or request that the target stops, and process the stop replies. However, this code is not what we use due to non-stop mode being disabled. So, we skip to the next step which is to call validate_exec_file. 4. Calling validate_exec_file can cause packets to be sent to the remote target, and replies received, the first path I hit is the call to target_pid_to_exec_file, which calls remote_target::pid_to_exec_file, which can then try to read the executable from the remote. Sending an receiving packets will make use of the remote_state::buf object. 5. The attempt to attach continues, but the damage is already done... So, the problem is that, in step #2 we cache a stop reply in the remote_state::buf, and then in step #4 we reuse the remote_state::buf object, discarding any cached stop reply. As a result, the initial stop, which is sent when GDB first attaches to the target, is lost. This problem can clearly be seen, I feel, by looking at the remote_state::cached_wait_status flag. This flag tells GDB if there is a wait status cached in remote_state::buf. However, in remote_target::putpkt_binary and remote_target::getpkt_or_notif_sane_1 this flag is just set back to 0, doing this immediately discards any cached data. I don't know if this scheme ever made sense, looking at commit 2d717e4f8a54, where the cached_wait_status flag was added, it appears that there was nothing between where the stop was cached, and where the stop was consumed, so, I suspect, there never was a situation where we ended up in putpkt_binary or getpkt_or_notif_sane_1 and needed to clear to the flag, maybe the clearing was added "just in case". Whatever the history, I claim that this clearing this flag is no longer a good idea. So, my first step toward fixing this issue was to replace the two instances of 'rs->cached_wait_status = 0;' in ::putpkt_binary and ::getpkt_or_notif_sane_1 with 'gdb_assert (rs->cached_wait_status == 0);', this, at least would show me when GDB was doing something dangerous, and indeed, this assert is now hit in my test case above. I did play with using some kind of scoped restore to backup, and restore the remote_state::buf object in all the places within remote.c that I was hitting where the ::buf was being corrupted. The first problem with this is that, where the ::cached_wait_status flag is reset is _not_ where ::buf is corrupted. For the ::putpkt_binary case, by the time we get to the method the buffer has already been corrupted in many cases, so we end up needing to add the scoped save/restore within the callers, which means we need the save/restore in _lots_ of places. Plus, using this save/restore model feels like the wrong solution. I don't think that it's obvious that the buffer might be holding cached data, and I think it would be too easy for new corruptions of the buffer to be introduced, which could easily go unnoticed for a long time. So, I really wanted a solution that didn't require us to cache data in the ::buf object. Luckily, I think we already have such a solution in place, the remote_state::stop_reply_queue, it seems like this does exactly the same task, just in a slightly different way. With the ::stop_reply_queue, the stop packets are processed upon receipt and the stop_reply object is added to the queue. With the ::buf cache solution, the unprocessed stop reply is cached in the ::buf, and processed later. So, finally, in this commit, I propose to remove the remote_state::cached_wait_status flag and to stop using the ::buf to cache stop replies. Instead, stop replies will now always be stored in the ::stop_reply_queue. There are two places where we use the ::buf to hold a cached stop reply, the first is in the ::attach method, and the second is in remote_target::start_remote, however, the second of these cases is far less problematic, as after caching the stop reply in ::buf we call the global start_remote function, which does very little work before calling normal_stop, which processes the cached stop reply. However, my plan is to switch both users over to using ::stop_reply_queue so that the old (unsafe) ::cached_wait_status mechanism can be completely removed. The next problem is that the ::stop_reply_queue is currently only used for async-mode, and so, in remote_target::push_stop_reply, where we push stop_reply objects into the ::stop_reply_queue, we currently also mark the async event token. I've modified this so we only mark the async event token if 'target_is_async_p ()' - note, _is_, not _can_ here. The ::push_stop_reply method is called in places where async mode has been temporarily disabled, but, when async mode is switched back on (see remote_target::async) we will mark the event token if there are events in the queue. Another change of interest is in remote_target::remote_interrupt_as. Previously this code checked ::cached_wait_status, but didn't check for events in the ::stop_reply_queue. Now that ::cached_wait_status has been removed we now check the queue length instead, which should have the same result. Finally, in remote_target::wait_as, I've tried to merge the processing of the ::stop_reply_queue with how we used to handle the ::cached_wait_status flag. Currently, when processing the ::stop_reply_queue we call process_stop_reply and immediately return. However, when handling ::cached_wait_status we run through the whole of ::wait_as, and return at the end of the function. If we consider a standard stop packet, the two differences I see are: 1. Resetting of the remote_state::waiting_for_stop_reply, flag; this is not currently done when processing a stop from the ::stop_reply_queue. 2. The final return value has the possibility of being adjusted at the end of ::wait_as, as well as there being calls to record_currthread, non of which are done if we process a stop from the ::stop_reply_queue. After discussion on the mailing list: https://sourceware.org/pipermail/gdb-patches/2021-December/184535.html it was suggested that, when an event is pushed into the ::stop_reply_queue, the ::waiting_for_stop_reply flag is never going to be set. As a result, we don't need to worry about the first difference. I have however, added a gdb_assert to validate the assumption that the flag is never going to be set. If in future the situation ever changes, then we should find out pretty quickly. As for the second difference, I have resolved this by having all stop packets taken from the ::stop_reply_queue, pass through the return value adjustment code at the end of ::wait_as. An example of a test that reveals the benefits of this commit is: make check-gdb \ RUNTESTFLAGS="--target_board=native-extended-gdbserver \ GDBFLAGS='-ex maint\ set\ target-async\ off \ -ex maint\ set\ target-non-stop\ off' \ gdb.base/attach.exp" For testing I've been running test on x86-64/GNU Linux, and run with target boards unix, native-gdbserver, and native-extended-gdbserver. For each board I've run with the default GDBFLAGS, as well as with: GDBFLAGS='-ex maint\ set\ target-async\ off \ -ex maint\ set\ target-non-stop\ off' \ Though running with the above GDBFLAGS is clearly a lot more unstable both before and after my patch, I'm not seeing any consistent new failures with my patch, except, with the native-extended-gdbserver board, where I am seeing new failures, but only because more tests are now running. For that configuration alone I see the number of unresolved go down by 49, the number of passes goes up by 446, and the number of failures also increases by 144. All of the failures are new tests as far as I can tell.
2021-12-17x86: Terminate mnemonicendp in swap_operand()Vladimir Mezentsev9-420/+421
Tested on x86_64-pc-linux-gnu. opcodes/ChangeLog: 2021-12-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * i386-dis.c (swap_operand): Terminate mnemonicendp. gas/ChangeLog: 2021-12-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * testsuite/gas/i386/opts-intel.d: Updated expected disassembly. * testsuite/gas/i386/opts.d: Likewise. * testsuite/gas/i386/sse2avx-opts-intel.d: Likewise. * testsuite/gas/i386/sse2avx-opts.d: Likewise. * testsuite/gas/i386/x86-64-opts-intel.d: Likewise. * testsuite/gas/i386/x86-64-opts.d: Likewise. * testsuite/gas/i386/x86-64-sse2avx-opts-intel.d: Likewise. * testsuite/gas/i386/x86-64-sse2avx-opts.d: Likewise.
2021-12-18Automatic date update in version.inGDB Administrator1-1/+1
2021-12-17Document gdbarch-components.pyTom Tromey1-0/+82
This adds a comment to document how to update gdbarch.
2021-12-17Remove gdbarch.shTom Tromey3-1879/+66
This patch runs gdbarch.py and removes gdbarch.sh.
2021-12-17Add new gdbarch generatorSimon Marchi1-0/+526
The new gdbarch generator is a Python program. It reads the "components.py" that was created in the previous patch, and generates gdbarch.c and gdbarch-gen.h. This is a relatively straightforward translation of the existing .sh code. It doesn't try very hard to be idiomatic Python or to be especially smart. It is, however, incredibly faster: $ time ./gdbarch.sh real 0m8.197s user 0m5.779s sys 0m3.384s $ time ./gdbarch.py real 0m0.065s user 0m0.053s sys 0m0.011s Co-Authored-By: Tom Tromey <tom@tromey.com>
2021-12-17Generate new gdbarch-components.py from gdbarch.shTom Tromey2-0/+2612
The new gdbarch.sh approach will be to edit a Python file, rather than adding a line to a certain part of gdbarch.sh. We use the existing sh code, though, to generate the first draft of this .py file. Documentation on the format will come in a subsequent patch. Note that some info (like "staticdefault") in the current code is actually unused, and so is ignored by this new generator.
2021-12-17Do not sort the fields in gdbarch_dumpTom Tromey2-521/+521
This changes gdbarch.sh so that it no longer sorts the fields in gdbarch_dump. This sorting isn't done anywhere else by gdbarch.sh, and this simplifies the new generator a little bit.
2021-12-17Do not generate gdbarch.hTom Tromey1-377/+0
Now that gdbarch.h has been split, we no longer need the generator code in gdbarch.sh, so remove it.
2021-12-17Split gdbarch.h into two filesTom Tromey3-1650/+1681
This patch splits gdbarch.h into two files -- gdbarch.h now is editable and hand-maintained, and the new gdbarch-gen.h file is the only thing generated by gdbarch.sh. This lets us avoid maintaining boilerplate in the gdbarch.sh file. Note that gdbarch.sh still generates gdbarch.h after this patch. This makes it easier to re-run when rebasing. This code is removed in a subsequent patch.
2021-12-17Move ordinary gdbarch code to arch-utilsTom Tromey4-1028/+488
While I think it makes sense to generate gdbarch.c, at the same time I think it is better for ordinary code to be editable in a C file -- not as a hunk of C code embedded in the generator. This patch moves this sort of code out of gdbarch.sh and gdbarch.c and into arch-utils.c, then has arch-utils.c include gdbarch.c.
2021-12-17Avoid redundant operations in `fortran_array_walker'Maciej W. Rozycki1-3/+4
Move inner dimension's element type determination outside the respective loops in `fortran_array_walker'. The operation is exactly the same with each iteration, so there is no point in redoing it for each element and while a smart compiler might be able to move it outside the loop it is regardless a bad coding style. No functional change.
2021-12-17Initialize `m_ndimensions' in the member initializer listMaciej W. Rozycki1-4/+3
Following our coding convention initialize the `m_ndimensions' member in the member initializer list rather than in the body of the constructor of the `fortran_array_walker' class. No functional change.
2021-12-17gdb/tui: install SIGWINCH only when connected to a TTYLancelot SIX4-3/+105
PR26056 reports that when GDB is connected to non-TTY stdin/stdout, it crashes when it receives a SIGWINCH signal. This can be reproduced as follows: $ gdb/gdb -nx -batch -ex 'run' --args sleep 60 </dev/null 2>&1 | cat # from another terminal: $ kill -WINCH %(pidof gdb) When doing so, the process crashes in a call to rl_resize_terminal: void rl_resize_terminal (void) { _rl_get_screen_size (fileno (rl_instream), 1); ... } The problem is that at this point rl_instream has the value NULL. The rl_instream variable is supposed to be initialized during a call to readline_initialize_everything, which in a normal startup sequence is called under this call chain: tui_interp::init tui_ensure_readline_initialized rl_initialize readline_initialize_everything In tui_interp::init, we have the following sequence: tui_initialize_io (); tui_initialize_win (); // <- Installs SIGWINCH if (gdb_stdout->isatty ()) tui_ensure_readline_initialized (); // <- Initializes rl_instream This function unconditionally installs the SIGWINCH signal handler (this is done by tui_initialize_win), and then if gdb_stdout is a TTY it initializes readline. Therefore, if stdout is not a TTY, SIGWINCH is installed but readline is not initialized. In such situation rl_instream stays NULL, and when GDB receives a SIGWINCH it calls its handler and in fine tries to access rl_instream leading to the crash. This patch proposes to fix this issue by installing the SIGWINCH signal handler only if GDB is connected to a TTY. Given that this initialization it the only task of tui_initialize_win, this patch moves tui_initialize_win just after the call to tui_ensure_readline_initialized. Tested on x86_64-linux. Co-authored-by: Pedro Alves <pedro@palves.net> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26056 Change-Id: I6458acef7b0d9beda2a10715d0345f02361076d9
2021-12-17asan: NULL dereference in bfd_elf_set_group_contentsAlan Modra2-6/+6
* elf-bfd.h (struct output_elf_obj_tdata): Make num_section_syms unsigned. * elf.c (bfd_elf_set_group_contents): Bounds check sec->index and check that entry in elf_section_syms for sec is non-NULL. (_bfd_elf_symbol_from_bfd_symbol): Adjust.
2021-12-17asan: use after free in _bfd_elf_mips_get_relocated_section_contentsAlan Modra1-5/+21
Leaving entries on mips_hi16_list from a previous pass over relocs leads to confusing bugs. * elfxx-mips.c (_bfd_elf_mips_get_relocated_section_contents): Free mips_hi16_list entries on error exit.
2021-12-17asan: abort in wasm_scan_name_function_sectionAlan Modra1-1/+2
Macros like READ_LEB128 in wasm-module.c that alter control flow are evil. Maintainers will break your code if you have hidden ways to reach labels. * wasm-module.c (wasm_scan_name_function_section): Don't attempt to bfd_release NULL.
2021-12-17asan: heap-buffer-overflow in bpf_elf_generic_relocAlan Modra1-8/+9
The bpf reloc howtos are a bit weird, using bitpos to specify an offset from r_offset that is outside the size of the reloc as given by howto.size. That means bfd_get_reloc_size gives the wrong answer for range checking, and thus bfd_reloc_offset_in_range can't be used. * elf64-bpf.c (bpf_elf_generic_reloc): Handle bitpos offset reloc range checking.
2021-12-17ubsan: bfd.c:2519:8: shift exponent 34 is too largeAlan Modra1-2/+2
* bfd.c (bfd_update_compression_header): Avoid integer overflow.
2021-12-17asan: buffer overflow in mmo_get_symbolsAlan Modra1-0/+10
* mmo.c (mmo_get_symbols): Error on symbol name exceeding max length.
2021-12-17asan: buffer overflow in elfnn-aarch64.c get_plt_typeAlan Modra1-3/+5
We can't assume .dynamic is a multiple of ElfNN_External_Dyn, at least not when presented with fuzzed object files. * elfnn-aarch64.c (get_plt_type): Don't access past end of improperly sized .dynamic.
2021-12-17try_build_id_prefix gcc-10 -Wformat-security errorsAlan Modra1-3/+2
dwarf.c:11300:3: error: format not a string literal and no format arguments [-Werror=format-security] 11300 | f += sprintf (f, prefix); PR 28697 * dwarf.c (try_build_id_prefix): Avoid -Wformat-security error.
2021-12-17Automatic date update in version.inGDB Administrator1-1/+1