Rainer Orth [Tue, 19 May 2020 08:06:00 +0000 (10:06 +0200)]
Avoid short i386 register names on Solaris/x86 [PR25981]
This is the 32-bit companion to
Remove unused ps_lgetLDT etc. on Solaris/x86 [PR25981]
https://sourceware.org/pipermail/gdb-patches/2020-May/168713.html
A 32-bit-default gdb fails to compile with the updated <sys/regset.h>.
While it is also affected by the lack of a GS definition, which the
compantion patch above fixes, it also fails to compile i386-sol2-nat.c like
this
/vol/src/gnu/gdb/hg/master/git/gdb/i386-sol2-nat.c:181:3: error: 'EAX' was not declared in this scope
181 | EAX, ECX, EDX, EBX,
| ^~~
and several more.
While this could be fixed by either including <ucontext.h> here or
provding fallback definitions of the register macros, I chose to do what
the 64-bit-default code in the same file
(amd64_sol2_gregset32_reg_offset[]) does, namely just hardcode the
numeric values instead. They are part of the ABI and thus guaranteed
not to change.
With this patch, a i386-pc-solaris2.11 configuration on master compiles
again, however, it doesn't work. However, I could successfully test it
on the gdb-9 branch.
Compiling and testing proved to be messy, unfortunately:
* For one, Solaris <sys/procfs.h> and largefile support used to be
mutually exclusive (fixed in Solaris 11.4 and Illumos), which was
exacerbated by the fact that g++ predefines _FILE_OFFSET_BITS=64 since
GCC 9.1.0. For now I've worked around this by adding
-U_FILE_OFFSET_BITS to CXXFLAGS and configuring with
--disable-largefile. I hope to clean this up in a future patch.
* gdb still defaults to startup-with-shell on. However, /bin/bash is a
64-bit executable which cannot be debugged by a 32-bit gdb. I hacked
around that part by pointing $SHELL at a 32-bit bash before running
make check.
Rainer Orth [Tue, 19 May 2020 08:03:14 +0000 (10:03 +0200)]
Remove unused ps_lgetLDT etc. on Solaris/x86 [PR25981]
As reported in PR build/25981, a future Solaris 11.4 update will soon
remove the short i386 register names like SS etc. from <sys/regset.h>.
They could leak into user code (e.g. via <signal.h> -> <sys/signal.h> ->
<sys/ucontext.h>) and pollute the user namespace. Affected code would
have a hard time avoiding the issue: LLVM is one of those.
While the short names are required to be present by the i386 psABI, that
document only demands that they exist in <ucontext.h>, which is what the
upcoming update assures.
With this change, in a 64-bit-default configuration, procfs.c fails to
compile on Solaris/x86:
/vol/src/gnu/gdb/hg/master/git/gdb/procfs.c: In function 'ssd* procfs_find_LDT_entry(ptid_t)':
/vol/src/gnu/gdb/hg/master/git/gdb/procfs.c:1643:18: error: 'GS' was not declared in this scope
1643 | key = (*gregs)[GS] & 0xffff;
| ^~
make[2]: *** [Makefile:1607: procfs.o] Error 1
Initially I meant to provide a definition using the planned replacement
macro, but closer inspection revealed a better way. procfs_find_LDT_entry
and its helper proc_get_LDT_entry are only used to implement ps_lgetLDT,
one of the callback functions required by libthread_db.so.1
(cf. <proc_service.h>). While that function is still documented as being
required even in Solaris 11.4, I found that calls to it had been removed
long ago in Solaris 9, so just removing the three functions above is the
easiest fix.
The following patch does just that. It compiled successfully on
amd64-pc-solaris2.11, however, as reported in PR gdb/25939, master is
completely broken on Solaris since the multi-target patch. The patch
applies cleanly to the gdb-9 branch and there I could test it
successfully.
A user on irc reported this as well, and with his help and the help of
a friend of his, we found that the problem occurred because, when
reloading a separate debug objfile, the objfile would lose the
OBJF_MAINLINE flag. This would cause some symbols from this separate
debug objfile to be marked "maybe_copied" -- but then
get_msymbol_address could find the same symbol and fail as reported.
This patch fixes the bug by preserving OBJF_MAINLINE.
No test case, unfortunately, because I could not successfully make
one.
gdb/ChangeLog
2020-04-10 Tom Tromey <tromey@adacore.com>
Ensure GDB printf command can print convenience var strings without a target.
GDB was extended in order to allow the printing of convenience
variables that are strings without a target. However, this introduced
a regression that hasn't been caught by our testsuite (because there
were no tests for it).
The problem happens when we try to print a convenience variable that
holds the address of a string in the inferior. The following
two-liners can reproduce the issue:
After some investigation, I found that the problem happens on
printcmd.c:printf_c_string. In the case above, we're taking the first
branch of the 'if' condition, which assumes that there will be a value
to be printed at "value_contents (value)". There isn't. We actually
need to obtain the address that the variable points to, and read the
contents from memory.
It seems to me that we should avoid this branch if the TYPE_CODE of
"value_type (value)" is TYPE_CODE_PTR (i.e., a pointer to the
inferior's memory). This is what this patch does.
I took the liberty to extend the current testcase under
gdb.base/printcmds.exp and create a test that exercises this scenario.
Eli Zaretskii [Sat, 22 Feb 2020 20:10:29 +0000 (22:10 +0200)]
Fix resizing of GDB TUI windows via 'winheight'.
gdb/ChangeLog:
2020-02-22 Eli Zaretskii <eliz@gnu.org>
PRE gdb/25586:
* tui/tui-win.c (new_height_ok, tui_adjust_win_heights): Rename
'locator' to 'status_line', to better match terminology in the
manual.
(tui_adjust_win_heights): Resize the status_line window to match
the new dimensions of the command and source/disassembly windows.
Reported by Aleksey Midenkov <midenok@gmail.com>.
projects / thirdparty / binutils-gdb.git / log
