aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-05-04sim: remove sys/times.h in most placesMike Frysinger6-3/+12
The v850 port used this, and then it got copied to other ports even though it wasn't needed. Clean it up to avoid portability issues on platforms not providing this (e.g. mingw64 for Windows).
2021-05-04sim: mips: fix qh_acc tableMike Frysinger2-1/+5
The AccAddLQH func was unused, and looking at this table, it looks like it's due to a typo.
2021-05-04sim: hw: localize init callbackMike Frysinger4-14/+13
Now that we don't need to hardcode the module init list in a single place, move the hw init logic out to the sim-hw file.
2021-05-04sim: microblaze: enable some basic trace pointsMike Frysinger3-0/+9
This isn't super complete, but it's useful enough as-is.
2021-05-04sim: microblaze: hook up libgloss syscallsMike Frysinger6-4/+54
When in the virtual environment, have brki 8 trigger libgloss syscalls like other ports. This also matches the ABI that Linux uses for its syscalls (ignoring the syscall table differences).
2021-05-05PowerPC undefweak testcaseAlan Modra5-0/+28
Test for commit 4916030821bb and b293661219c3. * testsuite/ld-powerpc/empty.s: New file. * testsuite/ld-powerpc/undefweak.d, * testsuite/ld-powerpc/undefweak.s: New testcase. * testsuite/ld-powerpc/powerpc.exp: Run it.
2021-05-05Automatic date update in version.inGDB Administrator1-1/+1
2021-05-04Add missing stdlib.h includes to simTom Tromey10-0/+26
This updates the various "mloop.in" files to emit an include of stdlib.h, to avoid warnings about 'abort' being undeclared. One such warning now remains, in mn10300.igen. I don't know offhand the best way to fix this one. 2021-05-04 Tom Tromey <tromey@adacore.com> * mloop.in: Include <stdlib.h>. sim/iq2000/ChangeLog 2021-05-04 Tom Tromey <tromey@adacore.com> * mloop.in: Include <stdlib.h>. sim/lm32/ChangeLog 2021-05-04 Tom Tromey <tromey@adacore.com> * mloop.in: Include <stdlib.h>. sim/m32r/ChangeLog 2021-05-04 Tom Tromey <tromey@adacore.com> * mloop.in: Include <stdlib.h>. sim/or1k/ChangeLog 2021-05-04 Tom Tromey <tromey@adacore.com> * mloop.in: Include <stdlib.h>.
2021-05-04Fix igen buildTom Tromey3-0/+8
The igen build fails for me like: gcc -g -O2 -c ../../binutils-gdb/sim/igen/igen.c -o igen/igen.o In file included from ../../binutils-gdb/sim/igen/igen.c:26: ../../binutils-gdb/sim/igen/lf.h:22:10: fatal error: ansidecl.h: No such file or directory This patch fixes the problem by arranging for igen to find the libiberty includes. This seems slightly hacky to me, because libiberty is not a "build" library, so it can't be linked against. However, since igen currently only includes the header, it seems relatively safe. 2021-05-04 Tom Tromey <tromey@adacore.com> * Makefile.in: Rebuild. * Makefile.am (AM_CPPFLAGS): New variable.
2021-05-04Add config.h to generated_files for simTom Tromey2-0/+5
I noticed that config.h isn't in 'generated_files' in the sim subdirectories. This causes it to sometimes be rebuilt too late. 2021-05-04 Tom Tromey <tromey@adacore.com> * Make-common.in (generated_files): Add config.h.
2021-05-04gnulib: import gendocsMike Frysinger10-4/+749
This will be used to generate more complete docs for the binutils site.
2021-05-04gnulib: import getlineMike Frysinger14-225/+1012
We use getline in sim today which breaks on older systems that are not compliant with the latest POSIX standard. For example, mingw64 for Windows omits getline so we fail to build there.
2021-05-04gdb/testsuite: adjust gdb.python/flexible-array-member.exp expected patternSimon Marchi2-4/+18
The `Type.range ()` tests in gdb.python/flexible-array-member.exp pass when the test is compiled with gcc 9 or later, but not with gcc 8 or earlier: $ make check TESTS="gdb.python/flexible-array-member.exp" RUNTESTFLAGS="CC_FOR_TARGET='gcc-8'" python print(zs['items'].type.range())^M (0, 0)^M (gdb) FAIL: gdb.python/flexible-array-member.exp: python print(zs['items'].type.range()) python print(zso['items'].type.range())^M (0, 0)^M (gdb) FAIL: gdb.python/flexible-array-member.exp: python print(zso['items'].type.range()) The value that we get for the upper bound of a flexible array member declared with a "0" size is 0 with gcc <= 8 and is -1 for gcc >= 9. This is due to different debug info. For this member, gcc 8 does: 0x000000d5: DW_TAG_array_type DW_AT_type [DW_FORM_ref4] (0x00000034 "int") DW_AT_sibling [DW_FORM_ref4] (0x000000e4) 0x000000de: DW_TAG_subrange_type DW_AT_type [DW_FORM_ref4] (0x0000002d "long unsigned int") For the same type, gcc 9 does: 0x000000d5: DW_TAG_array_type DW_AT_type [DW_FORM_ref4] (0x00000034 "int") DW_AT_sibling [DW_FORM_ref4] (0x000000e5) 0x000000de: DW_TAG_subrange_type DW_AT_type [DW_FORM_ref4] (0x0000002d "long unsigned int") DW_AT_count [DW_FORM_data1] (0x00) Ideally, GDB would present a consistent and documented value for an array member declared with size 0, regardless of how the debug info looks like. But for now, just change the test to accept the two values, to get rid of the failure and make the test in sync I also realized (by looking at the py-type.exp test) that calling the fields method on an array type yields one field representing the "index" of the array. The type of that field is of type range (gdb.TYPE_CODE_RANGE). When calling `.range()` on that range type, it yields the same range tuple as when calling `.range()` on the array type itself. For completeness, add some tests to access the range tuple through that range type as well. gdb/testsuite/ChangeLog: * gdb.python/flexible-array-member.exp: Adjust expected range value for member declared with 0 size. Test accessing range tuple through range type. Change-Id: Ie4e06d99fe9315527f04577888f48284d649ca4c
2021-05-04Define bfd_realloc(ptr,0) to return allocated memory, whilst ↵Nick Clifton4-23/+117
bfd_realloc_or_free(ptr,0) frees ptr. * libbfd.c (bfd_malloc): Provide some documenation. Treat a size of 0 as 1. (bfd_realloc): Likewise. (bfd_zmalloc): Likewise. (bfd_realloc_or_free): Provide some documentation. Treat a size of 0 as a request to free. * libbfd-in.h (bfd_realloc): Remove prototype. (bfd_realloc_or_free): Remove prototype. (bfd_zmalloc): Remove prototype. * libbfd.h: Regenerate.
2021-05-04Replace AC_PROG_CC with AC_PROG_CC_C99 in top level configure file.Nick Clifton3-1/+183
2021-05-04 Nick Clifton <nickc@redhat.com> * configure.ac (AC_PROG_CC): Replace with AC_PROG_CC_C99. * configure: Regenerate.
2021-05-04sim: add support for build-time ar & ranlibMike Frysinger68-66/+476
This is needed when building for a target whose ar & ranlib are incompatible with the current build system. For example, building for Windows on a Linux system. Then manually import the automake rule for libigen.a, but tweak the tool variables to use the FOR_BUILD variants.
2021-05-04sim: clean up bfd_vma printingMike Frysinger18-42/+79
A lot of this code predates the bfd_vma format define, so we have a random mix of casts to known types so we can printf the value. Use the BFD_VMA_FMT that now exists to simplify and reliability output across different build configs.
2021-05-04[gdb/guile] Don't allow libguile to change libgmp mem fnsTom de Vries2-0/+22
Since gdb commit 880ae75a2b7 "gdb delay guile initialization until gdbscm_finish_initialization" I'm running into: ... (gdb) print My_Var > 10.0^M free(): invalid pointer^M ERROR: GDB process no longer exists GDB process exited with wait status 5995 exp9 0 0 CHILDKILLED SIGABRT SIGABRT UNRESOLVED: gdb.ada/fixed_cmp.exp: gnat_encodings=all: print My_Var > 10.0 ... The problem is that both gdb and libguile try to set the libgmp memory functions, and since the gdb commit the ones from libguile are effective, which results in gdb freeing some memory in a way that is not compatible with the way that memory was actually allocated. The fact that libguile tries to set the libgmp memory functions is a bug which should be fixed starting version v3.0.6. Meanwhile, work around this in gdb by not allowing libguile to set the libgomp memory functions. Tested on x86_64-linux. gdb/ChangeLog: 2021-05-04 Tom de Vries <tdevries@suse.de> PR guile/27806 * guile/guile.c (gdbscm_initialize): Don't let guile change libgmp memory functions.
2021-05-04Automatic date update in version.inGDB Administrator1-1/+1
2021-05-03RISC-V: PR27764, Add tests for A extensionJim Wilson1-0/+8
ChangeLog entry for last patch.
2021-05-03RISC-V: PR27764, Add tests for A extensionChristoph Muellner4-0/+550
gas/ PR 27764 * testsuite/gas/riscv/a-ext-64.d: New testcase. * testsuite/gas/riscv/a-ext-64.s: Likewise. * testsuite/gas/riscv/a-ext.d: Likewise. * testsuite/gas/riscv/a-ext.s: Likewise. Signed-off-by: Christoph Muellner <cmuellner@gcc.gnu.org>
2021-05-03Fix x86_64 mingw buildTom Tromey2-1/+7
PR build/27807 points out that my recent changes to the Windows port missed a spot in win32-i386-low.cc -- a call to win32_Wow64GetThreadContext remained, causing link errors in gdbserver. This happened because I tested an i686 build, but this code is only used on an x86_64 build. This patch fixes the bug. I am checking it in. gdbserver/ChangeLog 2021-05-03 Tom Tromey <tromey@adacore.com> PR build/27807: * win32-i386-low.cc (i386_get_thread_context): Call Wow64GetThreadContext, not win32_Wow64GetThreadContext.
2021-05-03sim: add ATTRIBUTE_PRINTF / ATTRIBUTE_NULL_PRINTF where necessarySimon Marchi17-21/+50
I finally got the all-targets sim building with Clang, these are all the instances where an ATTRIBUTE_PRINTF or ATTRIBUTE_NULL_PRINTF attribute needed to be added to avoid errors like: /home/simark/src/binutils-gdb/sim/aarch64/../common/sim-profile.c:464:19: error: format string is not a string literal [-Werror,-Wformat-nonliteral] vfprintf (fp, fmt, ap); ^~~ There are more fixes needed to get everything building, but adding these attributes is trivial enough, so I send them all in a single patch. Adding the format attributes introduces some format string errors when building with GCC (because now format strings are checked), so corresponding changes are needed to avoid breaking the build. Other than simple format string specified changes, there is this one: /home/simark/src/binutils-gdb/sim/aarch64/../common/hw-events.c: In function 'hw_event_queue_schedule': /home/simark/src/binutils-gdb/sim/aarch64/../common/hw-events.c:95:15: error: too many arguments for format [-Werror=format-extra-args] 95 | NULL, dummy); | ^~~~~ We can fix it and avoid using a dummy variable by simply calling hw_event_queue_schedule_tracef instead of hw_event_queue_schedule_vtracef. sim/arm/ChangeLog: * armdefs.h (ARMul_ConsolePrint): Use format attribute. * wrapper.c (op_printf): Likewise. sim/bfin/ChangeLog: * interp.c (sim_open): Adjust format string specifier. sim/common/ChangeLog: * hw-events.h (hw_event_queue_schedule_tracef): Use format attribute. (hw_event_queue_schedule_vtracef): Likewise. * hw-tree.h (hw_tree_vparse): Likewise. * sim-profile.c (profile_vprintf): Likewise. * sim-trace.c (dis_printf): Likewise. * sim-trace.h (trace_printf): Likewise. (trace_vprintf): Likewise. * sim-utils.h (sim_do_commandf): Likewise. * hw-events.c (hw_event_queue_schedule): Use hw_event_queue_schedule_tracef. sim/rx/ChangeLog: * trace.c (op_printf): Likewise. sim/v850/ChangeLog: * interp.c (sim_open): Adjust format string specifier. Change-Id: I1445115ce57db15bb8e35dca93014555e7555794
2021-05-03x86: allow @secrel32 also in data definitionsJan Beulich4-7/+22
Now that lex_got() is uniform for all targets using it, permit COFF targets to also use @secrel32 with, in particular, .long. This is more natural than the custom .secrel32 directive, and also allows more flexibility (the "+six" form of the two added test lines doesn't work with a .secrel32 equivalent, in that it silently produces an unintended relocation type). As an extra benefit this also makes sure that data definitions in Intel syntax mode would get treated like they do for e.g. ELF targets.
2021-05-03x86: use UNIX EOL in secrel testcaseJan Beulich3-125/+130
For some reason these were using Windows EOL.
2021-05-03x86: fold both instances of lex_got()Jan Beulich2-106/+14
I see no reason at all for us to carry two copies of almost identical code. The differences, apart from the table entries, are benign. And the #ifdef-ary doesn't really get any worse.
2021-05-03x86: don't request useless overflow checkingJan Beulich3-40/+47
Relocations with a bitsize matching the architecture's address width can't usefully use an overflow checking approach other than "dont" or "signed": All others involve perhaps complex calculations in _bfd_relocate_contents() (or, not as severe, in bfd_check_overflow()) without ever finding anything to complain about - because of the address width masking applied. Avoid this unnecessary overhead and switch all such reloc types to "dont". Note that "signed" checking with rela relocations (i.e. x86-64 here) is only going to be useful if the addend actually got passed to _bfd_relocate_contents() (and maybe others) instead of bogusly adding in prior section contents (which apparently is assumed to be zero, and hence again no overflow would ever be detected). See https://sourceware.org/pipermail/binutils/2021-April/116164.html.
2021-05-03gdb/testsuite: update expected results in gdb.python/py-startup-opt.expAndrew Burgess2-1/+36
The test gdb.python/py-startup-opt.exp checks the behaviour of GDB's: set python dont-write-bytecode on This flag (when on) stops Python creating .pyc files. The test first checks that .pyc files will be created, then turns this option on and checks .pyc files will not be created. However, if the user has PYTHONDONTWRITEBYTECODE set in their environment then this will prevent Python from creating .pyc files, as such the first test, that .pyc files are being created, currently fails. We could unset PYTHONDONTWRITEBYTECODE, however, until Python 3.8 there is no way to control where Python writes the .pyc files. As the GDB developer clearly doesn't want .pyc files created in their file-system it feels wrong to silently unset this environment variable. My proposal then, is that we just spot when this environment variable is set and adjust the expected results. My hope is that across all GDB developers some will be running with PYTHONDONTWRITEBYTECODE unset, so this feature will be fully tested at least some of the time. gdb/testsuite/ChangeLog: PR testsuite/27788 * gdb.python/py-startup-opt.exp (test_python_settings): Change the expected results when environment variable PYTHONDONTWRITEBYTECODE is set.
2021-05-03PPC: undefweak dynamic relocsAlan Modra3-2/+18
This makes the default for ppc to keep dynamic relocs on undefweak symbols when the code won't cause DT_TEXTREL (for instance when -fPIE or -fPIC). If ld is given -z dynamic-undefined-weak then dynamic relocations will be created for non-PIC at the expense of possibly causing DT_TEXTREL to be set on ppc32. Note that DT_TEXTREL and GNU indirect functions are incompatible. * elf32-ppc.c (allocate_dynrelocs): Keep dyn_relocs for undefweak symbols when -z dynamic-undefined-weak or when there are no dynamic relocs in read-only sections and -z nodynamic-undefined-weak is not given. * elf64-ppc.c (allocate_dynrelocs): Likewise.
2021-05-03PPC: ensure_undef_dynamic on weak undef only in pltAlan Modra3-2/+16
It's slightly weird to have a call to a weak function not protected by a test of that function being non-NULL, but the non-NULL test might be covered by a test of another function. For example: if (func1) { func1 (); func2 (); } where func2 is known to exist if func1 exists. * elf32-ppc.c (allocate_dynrelocs): Call ensure_undef_dynamic for weak undefined symols that only appear on PLT relocs. * elf64-ppc.c (allocate_dynrelocs): Likewise.
2021-05-03PR27755, powerpc-ld infinite loopAlan Modra2-1/+6
PR 27755 * elf32-ppc.c (ppc_elf_inline_plt): Do increment rel in loop.
2021-05-03csky: fix annobin test failsAlan Modra2-0/+42
* elf32-csky.c (is_mapping_symbol_name): New function. (csky_elf_is_target_special_symbol): Likewise. (csky_elf_maybe_function_sym): Likewise. (bfd_elf32_bfd_is_target_special_symbol): Define. (elf_backend_maybe_function_sym): Define.
2021-05-03testsuite: Don't start directives in first columnAlan Modra3-14/+20
Fixes fails on hppa64-hp-hpux11.23 * testsuite/gas/elf/section25.s: Don't start directives in first column. * testsuite/gas/elf/section26.s: Likewise.
2021-05-03Re: section symbols without a nameAlan Modra2-1/+6
commit 23356397449 changed this file but missed one place. * testsuite/ld-s390/tlspic_64.rd: Adjust expected output for named section symbols.
2021-05-03Automatic date update in version.inGDB Administrator1-1/+1
2021-05-02sim: add default cases to two switches in sim-options.cSimon Marchi2-0/+7
This is the next compilation error I hit when I build all targets with Clang: /home/simark/src/binutils-gdb/sim/aarch64/../common/sim-options.c:234:12: error: no case matching constant switch condition '0' [-Werror] switch (WITH_ENVIRONMENT) ^~~~~~~~~~~~~~~~ ./config.h:215:26: note: expanded from macro 'WITH_ENVIRONMENT' #define WITH_ENVIRONMENT ALL_ENVIRONMENT ^~~~~~~~~~~~~~~ /home/simark/src/binutils-gdb/sim/aarch64/../common/sim-options.c:276:15: error: no case matching constant switch condition '0' [-Werror] switch (WITH_ALIGNMENT) ^~~~~~~~~~~~~~ /home/simark/src/binutils-gdb/sim/aarch64/../common/sim-config.h:220:24: note: expanded from macro 'WITH_ALIGNMENT' #define WITH_ALIGNMENT 0 ^ This is a little bit special because these are switches on compile-time value. But regardless, the idea is that we logically can't reach the switches if WITH_ENVIRONMENT == 0 or WITH_ALIGNMENT == 0, so the code is correct. In addition to getting rid of the compiler warning, adding default cases to these switches ensure that if we do get in an unexpected situation, it is caught. In GDB, I'd use gdb_assert_not_reached, I don't know if there is something similar in sim so I went with abort. sim/common/ChangeLog: * sim-options.c (standard_option_handler): Add default cases to switches. Change-Id: Ie237d67a201caa6b72de0d17cc815193417156b6
2021-05-02sim: replace custom attributes with ansidecl.hMike Frysinger20-63/+79
A lot of this code predates the common attributes. We had already started migrating over piece by piece, so just do a pass across all the attributes and replace most of them.
2021-05-01sim: bfin: move option inits to respective modulesMike Frysinger4-13/+30
Now that modules can self declare their own init funcs, change the mmu and mach logic to use it. We don't need to export the option symbols or specifically call this logic from the sim_open function anymore.
2021-05-01sim: options: fix --help outputMike Frysinger2-0/+5
The hash table rewrite broke --help output due to subtle behavior: calling dup_arg_p(NULL) will create & clear the table, not just create it. The --help output relies on this to clear the table before it shows things.
2021-05-01sim: dv-sockser: localize init callbackMike Frysinger4-12/+12
Now that we don't need to hardcode the module init list in a single place, move the dv-sockser logic to the place to the one file.
2021-05-01sim: mips: mark local func staticMike Frysinger2-1/+5
2021-05-01sim: add framework for declaring init callbacks locallyMike Frysinger4-16/+74
To facilitate decentralized module initialization/registration with an eye towards multi-target support, add a framework to detect init calls declared in the source and automatically call them. This is akin to gdb's _initialize_xxx framework for letting modules autodiscover.
2021-05-02Automatic date update in version.inGDB Administrator1-1/+1
2021-05-01sim: nrun: add local strsignal prototypeMike Frysinger97-62/+386
While libiberty provides a definition for this for systems that lack the function (e.g. Windows), it doesn't provide a prototype. So add our own local copy in the one file that uses the func.
2021-05-01sim: rx: cast bfd_vma when printingMike Frysinger2-1/+5
A bit of a hack, but it's what we've been doing so far when printing bfd_vma's since bfd doesn't provide PRI helper types for us to use.
2021-05-01sim: riscv: fix building on 32-bit hosts w/out int128Mike Frysinger2-1/+5
Check for __SIZEOF_INT128__ before trying to use the builtin type. This fixes building on some 32-bit systems like x86.
2021-05-01sim: aarch64: use PRIx64 for formatting 64-bit typesMike Frysinger2-5/+12
We can't assume that %lx is big enough for 64-bit types as it isn't on most 32-bit builds. Use the standard format define for this instead.
2021-05-01sim: aarch64: fix 64-bit immediate shiftsMike Frysinger2-2/+6
Trying to shift immediates 63 bits fails on 32-bit systems since UL is only 32-bits, not 64-bits. Switch to ULL to guarantee at least 64-bits here.
2021-05-01sim: arm: move build logic to source filesMike Frysinger3-9/+25
This simplifies the build logic a bit by just having source file inputs. It also simplifies code that assumes there's a source file for each object.
2021-05-01sim: callback: inline wrap helperMike Frysinger2-25/+66
This is annoying as it requires inlining boiler plate, but we don't have much choice: the wrap helper assumes the return value is always an int, but that's already not the case with some of the callbacks which use long. GCC has extensions to define macros-as-functions, but we can't assume GCC.
generated by cgit v1.1 at 2024-11-19 16:41:26 +0000