Replace the extended state area fields of i387_xsave with methods which
return an offset into the XSAVE buffer.
The two changed functions are called within all tests which runs
gdbserver.
Signed-off-by: Aleksandar Paunovic <aleksandar.paunovic@intel.com>
Co-authored-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Legacy fields of the XSAVE area are already defined within fx_save
struct. Use class inheritance to remove code duplication.
The two changed functions are called within all tests which run
gdbserver.
Signed-off-by: Aleksandar Paunovic <aleksandar.paunovic@intel.com>
Co-authored-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Make x86_xcr0 private to i387-fp.cc and use i387_set_xsave_mask to set
the value instead. Add a static global instance of x86_xsave_layout
and initialize it in the new function as well to be used in a future
commit to parse XSAVE extended state regions.
Update the Linux port to use this function rather than setting
x86_xcr0 directly. In the case that XML is not supported, don't
bother setting x86_xcr0 to the default value but just omit the call to
i387_set_xsave_mask as i387-fp.cc defaults to the SSE case used for
non-XML.
In addition, use x86_xsave_length to determine the size of the XSAVE
register set via CPUID.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
All of the tables describing the offsets of individual registers for
XSAVE state components now hold relative offsets rather than absolute
offsets. Some tables (those for MPX registers and ZMMH registers) had
to be split into separate tables as they held entries that spanned
multiple state components.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Note that this uses the CPUID instruction to determine the total size
of the XSAVE register set. If there is a way to fetch the register set
size using ptrace that would probably be better.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Refactor i386_linux_core_read_xcr0 to fetch and return a corresponding
x86_xsave_layout as well as xcr0 using the size of an existing
NT_X86_XSTATE core dump to determine the offsets via
i387_guess_xsave_layout. Use this to add an implementation of
gdbarch_core_xfer_x86_xsave_layout.
Use tdep->xsave_layout.sizeof_xsave as the size of the XSTATE register
set.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Refactor i386fbsd_core_read_xcr0 to fetch and return a corresponding
x86_xsave_layout as well as xcr0 using the size of an existing
NT_X86_XSTATE core dump to determine the offsets via
i387_guess_xsave_layout. Use this to add an implementation of
gdbarch_core_xfer_x86_xsave_layout.
Use tdep->xsave_layout.sizeof_xsave as the size of the XSTATE register
set and only fetch/store the register set if this size is non-zero.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
x86_xsave_length returns the total length of the XSAVE state area
standard format as queried from CPUID.
x86_fetch_xsave_layout uses CPUID to query the offsets of XSAVE
extended regions from the running host. The total length of the XSAVE
state area can either be supplied by the caller if known (e.g. from
FreeBSD's PT_GETXSTATEINFO) or it can be queried from the running host
using x86_xsave_length.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Add gdbarch_core_read_x86_xsave_layout to fetch the x86 XSAVE layout
structure from a core file.
Current OS's do not export the offsets of XSAVE state components in
core dumps, so provide an i387_guess_xsave_layout helper function to
set offsets based on known combinations of XCR0 masks and total state
sizes. Eventually when core dumps do contain this information this
function should only be used as a fall back for older core dumps.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This structure is fetched from the current target in i386_gdbarch_init
via a new "fetch_x86_xsave_layout" target method.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The standard layout of the XSAVE extended state area consists of three
regions. The first 512 bytes (legacy region) match the layout of the
FXSAVE instruction including floating point registers, MMX registers,
and SSE registers. The next 64 bytes (XSAVE header) contains a header
with a fixed layout. The final region (extended region) contains zero
or more optional state components. Examples of these include the
upper 128 bits of YMM registers for AVX.
These optional state components generally have an
architecturally-fixed size, but they are not assigned architectural
offsets in the extended region. Instead, processors provide
additional CPUID leafs describing the size and offset of each
component in the "standard" layout for a given CPU. (There is also a
"compact" format which uses an alternate layout, but existing OS's
currently export the "standard" layout when exporting XSAVE data via
ptrace() and core dumps.)
To date, GDB has assumed the layout used on current Intel processors
for state components in the extended region and hardcoded those
offsets in the tables in i387-tdep.c and i387-fp.cc. However, this
fails on recent AMD processors which use a different layout.
Specifically, AMD Zen3 and later processors do not leave space for the
MPX register set in between the AVX and AVX512 register sets.
To rectify this, add an x86_xsave_layout structure which contains the
total size of the XSAVE extended state area as well as the offset of
each known optional state component.
Subsequent commits will modify XSAVE parsing in both gdb and gdbserver
to use x86_xsave_layout.
Co-authored-by: Aleksandar Paunovic <aleksandar.paunovic@intel.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Mark Wielaard pointed out that cooked_index::dump uses PRIx64, and
Andreas Schwab pointed out that gdb already has sect_offset_str. This
patch applies both these observations.
The getsymname function uses PRIxPTR to print and uintptr_t value in
an error message. Use hex_string instead.
Approved-By: Tom Tromey <tom@tromey.com>
Building gdb with gcc 7.5.0 and -flto -O2 -flto-partition=one generates a
self-referencing DIE:
...
<2><91dace>: Abbrev Number: 405 (DW_TAG_label)
<91dad0> DW_AT_abstract_origin: <0x91dace>
...
When encountering the self-reference DIE in inherit_abstract_dies we loop
following the abstract origin, effectively hanging gdb.
Fix this by handling self-referencing DIEs in the loop in
inherit_abstract_dies.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30799
https://sourceware.org/bugzilla/show_bug.cgi?id=30799
A low level function like coff_swap_aux_in really has no business
concatenating multiple auxents for the old PE multi-aux scheme of
handling long file names. In doing so, it assumes multiple internal
auxent buffers are available, which they are not in most calls to
bfd_coff_swap_aux_in, both inside BFD and outside, eg. GDB. Buffer
overflow fun. Concatenating multiple auxents belongs at a higher
level.
This required some changes to coff_get_normalized_symtab, which now
uses the external auxents to access the concatenated file name.
(Internal auxents are larger than the x_fname array, so the pieces of
the file name are not adjacent as they are in the external auxents.)
* coffswap.h (coff_swap_aux_in): Do not write more than one
internal auxent.
* coffcode.h (coff_bigobj_swap_aux_in): Likewise.
* coffgen.c (coff_get_normalized_symtab): Normalize strings
after swapping in each symbol so that external auxents are
available. Use external auxents for multi-aux long file
names. Formatting. Wrap long lines. Remove excess parens
and unnecessary casts. Don't zalloc when only the string
terminator needs zeroing, and memcpy rather than strncpy.
Delete unnecessary sanity check with unsigned _n_offset.
Return with failure if debug section can't be read, to avoid
trying to read it multiple times. Correct sanity check
against debug section size.
I missed another field that needs freeing. Also, oss-fuzz found a
case with a C_FILE sym using multiple auxents for a long file name
which overflowed the single auxent buffer. I'm going to fix that
problem in swap_aux_in too, but we may as well avoid it here too,
saving unnecessary work.
* coffcode.h (comdat_delf): Free comdat_name.
(fill_comdat_hash): Only look at symbols with one auxent.
When running test-cases gdb.cp/*.exp with gcc 4.8.4, I run into compilation
failures due to the test-cases requiring c++11 and the compiler defaulting
to less than that.
Fix this by compiling with -std=c++11.
This exposes two FAILs in gdb/testsuite/gdb.cp/empty-enum.exp due to
gcc PR debug/16063, so xfail those.
Also require have_compile_flag -std=c++17 in gdb.cp/constexpr-field.exp to
prevent compilation failure.
Tested on x86_64-linux.
Following the arrangement in GCC select a 64-bit ABI by default, either
n32 or n64, rather than o32 for `mipsisa64*-*-linux*' targets, just as
with the corresponding `mips64*-*-linux*' targets.
Only mips*el triples are supported by binutils. The mips*le
or mips*el* may cause some problem with other components of
binutils, since they will consider them as big endian.
EM_MIPS_RS3_LE has been deprecated quite long ago, and in fact
most of current LE ELF files are using EM_MIPS.
This problem didn't make some trouble for us, is due to that
gold is a linker, and all of the inputs to it has right EM values.
I was looking at dos_message and wondering why we have H_PUT_32
in _bfd_XXi_only_swap_filehdr_out but no H_GET_32 in pe_bfd_object_p.
On a big-endian machine this would result in scrambling the code and
strings constained in dos_message. Rather than fix the lack of
H_GET_32 in pe_bfd_object_p, I decided it doesn't make sense to store
dos_message internally as an array of ints.
include/
* coff/internal.h (struct internal_extra_pe_filehdr): Make
dos_message a char array.
* coff/msdos.h (struct external_DOS_hdr): Flatten dos_message.
* coff/pe.h (struct external_PEI_filehdr): Likewise.
bfd/
* libcoff-in.h (struct pe_tdata): Make dos_message a char array.
* libcoff.h: Regenerate.
* peXXigen.c (_bfd_XXi_only_swap_filehdr_out): memcpy dos_message
to output.
* peicode.h (pe_mkobject): Don't memset already zeroed pe_opthdr.
Tidy allocation of tdata.pe_obj_data. Set up dos_message from..
(default_dos_message): ..this. New static array.
Entries added to the hash table with bfd_malloc ought to be freed when
the hash table is deleted. This patch adds the necessary del_f to the
htab_create call, and delays creating the table until an
IMAGE_SCN_LNK_COMDAT symbol is read.
* peicode.h (pe_mkobject): Move comdat_hash creation..
(htab_hash_flags, htab_eq_flags): ..and these support functions..
* coffcode.h (handle_COMDAT): ..to here, renaming support to
(comdat_hashf, comdat_eqf): ..this and adding..
(comdat_delf): ..this new function.
A bfd_cleanup function needs to run when only tdata is correct for the
bfd. The xvec may have changed during bfd_check_format and thus the
flavour may be incorrect. The format won't have changed but checking
is superfluous. (In contrast to _bfd_free_cached_info or
_close_and_cleanup where we do need to check things.)
Not getting this correct leaked comdat_hash.
Also, pe_ILF_cleanup ought to call coff_object_cleanup as do all PE
files.
* coffgen.c (coff_object_cleanup): Don't check bfd flavour or
format.
* peicode.h (pe_ILF_cleanup): Call coff_object_cleanup.
Sanity check aux entries used by PE to extend a C_FILE name. See
coffswap.h:coff_swap_aux_in. The existing check only catered for
n_numaux == 1.
* coffcode.h (fill_comdat_hash): Properly sanity check n_numaux.
Formatting.
(handle_COMDAT): Formatting.
This patch sets GUILE to just plain 'guile'.
In the distant ("devo") past, the top-level build did support building
Guile in-tree. However, I don't think this really works any more.
For one thing, there are no build dependencies on it, so there's no
guarantee it would actually be built before the uses.
This patch also removes the use of "-s" as an option to cgen scheme
scripts. With my latest patch upstream, this is no longer needed.
After the upstream changes, either Guile 2 or Guile 3 will work, with
or without the compiler enabled.
2023-08-24 Tom Tromey <tom@tromey.com>
* cgen.sh: Don't pass "-s" to cgen.
* Makefile.in: Rebuild.
* Makefile.am (GUILE): Simplify.
The author of 'mold' pointed out that with a certain shared library,
gdb would fail to find the shared library's name in 'bt'.
The function in question appeared at the end of the .so's .text
segment and ended with a call to 'abort'.
This turned out to be a classic case of calling get_frame_pc when
get_frame_address_in_block is needed -- the former will be off-by-one
for purposes of finding the enclosing function or shared library.
The included test fails without the patch on my system. However, I
imagine it can't be assumed to reliably fail. Nevertheless it seemed
worth doing.
Regression tested on x86-64 Fedora 38.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29074
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
i386: warning: format ‘%u’ expects argument of type ‘unsigned int’,
but argument 4 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
ia64: warning: ignoring return value of ‘fgets’
* i386-gen.c (process_i386_opcodes): Correct format string.
* ia64-gen.c (load_insn_classes, load_depfile): Don't ignore
fgets return value.
This patch gets rid of the individual rules including the .Pc
dependency files made while generating e*.c files, replacing them with
a fancy GNU make pattern include. I've also moved creation of
ldscripts to the makefile since it is possible to run more than one
genscripts at once, resulting in "ldscripts: File exists" messages.
* Makefile.am: Replace individual include of *.Pc dependency
files with one pattern rule.
(.Pc): New dummy rule.
(ldscripts/stamp): New rule.
(GEN_DEPENDS): Add ldscripts/stamp.
(install-data-local): Exclude ldscripts/stamp from install.
* genscripts.sh: Don't make ldscripts dir.
* Makefile.in: Regenerate.
The getsymname function tries to emit an error using %ld for an
uintptr_t argument. Use PRIxPTR instead. Which works on any architecture
for uintptr_t.
This patch addresses an issue with malformed/fuzzed debug information that
was recently reported in gdb/30639. That bug specifically deals with
an ASAN issue, but the reproducer provided by the reporter causes a
another failure outside of ASAN:
$ ./gdb --data-directory data-directory -nx -q UAF_2
Reading symbols from /home/keiths/UAF_2...
Fatal signal: Segmentation fault
----- Backtrace -----
0x59a53a gdb_internal_backtrace_1
../../src/gdb/bt-utils.c:122
0x59a5dd _Z22gdb_internal_backtracev
../../src/gdb/bt-utils.c:168
0x786380 handle_fatal_signal
../../src/gdb/event-top.c:889
0x7864ec handle_sigsegv
../../src/gdb/event-top.c:962
0x7ff354c5fb6f ???
0x611f9a process_coff_symbol
../../src/gdb/coffread.c:1556
0x611025 coff_symtab_read
../../src/gdb/coffread.c:1172
0x60f8ff coff_read_minsyms
../../src/gdb/coffread.c:549
0x60fe4b coff_symfile_read
../../src/gdb/coffread.c:698
0xbde0f6 read_symbols
../../src/gdb/symfile.c:772
0xbde7a3 syms_from_objfile_1
../../src/gdb/symfile.c:966
0xbde867 syms_from_objfile
../../src/gdb/symfile.c:983
0xbded42 symbol_file_add_with_addrs
../../src/gdb/symfile.c:1086
0xbdf083 _Z24symbol_file_add_from_bfdRKN3gdb7ref_ptrI3bfd18gdb_bfd_ref_policyEEPKc10enum_flagsI16symfile_add_flagEPSt6vectorI14other_sectionsSaISC_EES8_I12objfile_flagEP7objfile
../../src/gdb/symfile.c:1166
0xbdf0d2 _Z15symbol_file_addPKc10enum_flagsI16symfile_add_flagEPSt6vectorI14other_sectionsSaIS5_EES1_I12objfile_flagE
../../src/gdb/symfile.c:1179
0xbdf197 symbol_file_add_main_1
../../src/gdb/symfile.c:1203
0xbdf13e _Z20symbol_file_add_mainPKc10enum_flagsI16symfile_add_flagE
../../src/gdb/symfile.c:1194
0x90f97f symbol_file_add_main_adapter
../../src/gdb/main.c:549
0x90f895 catch_command_errors
../../src/gdb/main.c:518
0x9109b6 captured_main_1
../../src/gdb/main.c:1203
0x910fc8 captured_main
../../src/gdb/main.c:1310
0x911067 _Z8gdb_mainP18captured_main_args
../../src/gdb/main.c:1339
0x418c71 main
../../src/gdb/gdb.c:39
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible. GDB will now terminate.
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
Segmentation fault (core dumped)
The issue here is that the COFF offset for the fuzzed symbol's
name is outside the string table. That is, the offset is greater
than the actual string table size.
coffread.c:getsymname actually contains a FIXME about this, and that's
what I've chosen to address to fix this issue, following what is done
in the DWARF reader:
$ ./gdb --data-directory data-directory -nx -q UAF_2
Reading symbols from /home/keiths/UAF_2...
COFF Error: string table offset (256) outside string table (length 0)
(gdb)
Unfortunately, I haven't any idea how else to test this patch since
COFF is not very common anymore. GCC removed support for it five
years ago with GCC 8.
In AIX the first eight function parameters are stored from R3 to R10.
If there are more than eight parameters in a function then we store the 9th parameter onwards in the stack.
While doing so, in 64 bit mode the words were not zero extended and was coming like 32 bit mode.
This patch is a fix to the same.
While documented to not be reliable, it is still odd for objcopy to
silently produce bad output when converting COFF/PE object files to ELF
ones. The issue there is that relocation addends all are screwed up by
subtracting the symbol's section offset. In the COFF/PE world, to my
knowledge, section contents stores the addends alone, not the result of
symbol value plus addend. Hence the compensation talked about in a
comment ahead of the sole use site of CALC_ADDEND() may need to account
for the VMA (which is always zero for object files anyway), but not for
the symbol value.
The coff-sh.c adjustment is based upon guessing that behavior there is
the same. Note also how coff-aarch64.c short-circuits CALC_ADDEND()
altogether, which may suggest that a much simpler macro might do for the
COFF_WITH_PE case in the three arch-specific files touched here.
For (at least) Arm/WinCE this actually results in more appropriate
objdump output as well, as can be seen in the one testcase which has its
expectations adjusted (the generated binary doesn't change).
Rather than special-casing rx-*-* for section30, force use of
conventional section names uniformly. By further passing $dump_opts to
a few more tests, a number of xfail-s (and one notarget) can be
eliminated (some of which had wrong justifications in associated
comments anyway). Note that section7 and section15 need to be left
alone: The harness fiddling with section names there didn't help before
and is getting in the way now. For section12b, section16b, and most of
the Dwarf tests nothing changes. Interestingly by passing $dump_opts
the need to xfail section11 for LoongArch and RISC-V also goes away.
While --sectname-subst is nice, it isn't enough to e.g. mimic
-f{function,data}-sections in assembly code, when such use is to be
optional (e.g. dependent upon some configuration setting).
Assign meaning to '+' and '-' as section attribute letters, allowing
to inherit the prior section's attributes (and possibly type) along
with adding or removing some. Note that documenting the interaction
with '?' as undefined is a precautionary measure.
While touching the function invocation, stop using |= on the result of
obj_elf_parse_section_letters(): "attr" is firmly zero ahead of the
call.
Use the pattern rule in a comment from commit 77ac17b845.
* Makefile.am (run-genscripts): Delete. Use pattern rule
e%.c instead.
* Makefile.in: Regenerate.
Code in som_write_symbol_strings neglected to allow for padding, which
can result in a buffer overflow. It also used xrealloc, which we're
not supposed to use in libbfd because libbfd isn't supposed to call
exit. Also a realloc is perhaps not a good idea when none of the
buffer contents are needed, so replace with free, bfd_malloc. There
were three copies of the string handling code, so rather than fix them
all I've extracted them to a function. This necessitated making one
of the fields in struct som_symbol unsigned.
* som.c (add_string): New function.
(som_write_space_strings, som_write_symbol_strings): Use it.
* som.h (som_symbol_type <stringtab_offset>): Make unsigned.
