aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-01-10sim: rx: move libsim.a creation to top-levelMike Frysinger3-42/+87
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: rl78: move libsim.a creation to top-levelMike Frysinger3-41/+78
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: riscv: move libsim.a creation to top-levelMike Frysinger3-31/+83
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: pru: move libsim.a creation to top-levelMike Frysinger3-31/+80
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: or1k: move libsim.a creation to top-levelMike Frysinger3-52/+122
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: msp430: move libsim.a creation to top-levelMike Frysinger3-37/+86
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: moxie: move libsim.a creation to top-levelMike Frysinger3-37/+87
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: mn10300: move libsim.a creation to top-levelMike Frysinger3-46/+118
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: mips: move libsim.a creation to top-levelMike Frysinger5-153/+251
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects. The mips code is a little more tricky than others because, for multi-run targets, it generates the list of sources & objects on the fly in the configure script.
2023-01-10sim: microblaze: move libsim.a creation to top-levelMike Frysinger3-57/+106
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: mcore: move libsim.a creation to top-levelMike Frysinger3-57/+105
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: m68hc11: move libsim.a creation to top-levelMike Frysinger3-67/+132
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: m32r: move libsim.a creation to top-levelMike Frysinger3-77/+186
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: m32c: move libsim.a creation to top-levelMike Frysinger3-90/+136
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: lm32: move libsim.a creation to top-levelMike Frysinger3-82/+167
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: iq2000: move libsim.a creation to top-levelMike Frysinger3-87/+165
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: h8300: move libsim.a creation to top-levelMike Frysinger3-83/+132
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: ft32: move libsim.a creation to top-levelMike Frysinger3-86/+133
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: frv: move libsim.a creation to top-levelMike Frysinger3-96/+209
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: example-synacor: move libsim.a creation to top-levelMike Frysinger3-91/+143
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: erc32: move libsim.a creation to top-levelMike Frysinger3-100/+148
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: d10v: move libsim.a creation to top-levelMike Frysinger3-104/+157
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: cris: move libsim.a creation to top-levelMike Frysinger3-115/+205
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: cr16: move libsim.a creation to top-levelMike Frysinger3-116/+167
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: bpf: move libsim.a creation to top-levelMike Frysinger3-126/+207
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: bfin: move libsim.a creation to top-levelMike Frysinger3-125/+181
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: avr: move libsim.a creation to top-levelMike Frysinger3-121/+168
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: arm: move libsim.a creation to top-levelMike Frysinger3-125/+181
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: aarch64: move libsim.a creation to top-levelMike Frysinger4-129/+184
The objects are still compiled in the subdir, but the creation of the archive itself is in the top-level. This is a required step before we can move compilation itself up, and makes it easier to review. The downside is that each object compile is a recursive make instead of a single one. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2023-01-10sim: build: drop support for subdir extra depsMike Frysinger2-17/+0
Nothing uses this hook anymore, so punt it. It was largely used to track generated files (which we do in the top-level now) and extra header files (which we use automake depgen for now).
2023-01-10sim: modules: trigger generation from top-levelMike Frysinger18-10/+67
Add rules for tracking generated subdir modules.c files. This doesn't actually generate the file from the top-level, but allows us to add rules that need to be ordered wrt it. Once those changes land, we can rework this to actually generate from the top-level. This currently builds off of the objects that go into the libsim.a as we don't build those from the top-level either. Once we migrate that up, we can switch this to the source files directly. It's a bit hacky overall, but makes it easier to migrate things in smaller chunks, and we aren't going to keep this logic long term.
2023-01-09gdb/linespec.c: Fix missing source file during breakpoint re-setAaron Merey2-2/+11
During breakpoint re-setting, the source_filename of an explicit_location_spec is used to lookup the symtabs associated with the breakpoint being re-set. This source_filename is compared with each known symtab filename in order to retrieve the breakpoint's symtabs. However the source_filename may have been originally copied from a symtab's fullname (the path where GDB found the source file) when the breakpoint was first created. If a breakpoint symtab's filename and fullname differ and there is no substitute-path rule that converts the fullname to the filename, this will cause a NOT_FOUND_ERROR to be thrown during re-setting. Fix this by using a symtab's filename to set the explicit_location_spec source_filename instead of the symtab's fullname.
2023-01-09gdb/linespec.c: Fix -Wmaybe-uninitialized warningAaron Merey1-1/+1
Although the bool want_start_sal isn't actually used without being assigned a value, initialize it to be false in order to prevent the following -Wmaybe-uninitialized warning: linespec.c: In function ‘void minsym_found(linespec_state*, objfile*, minimal_symbol*, std::vector<symtab_and_line>*)’: linespec.c:4150:19: warning: ‘want_start_sal’ may be used uninitialized [-Wmaybe-uninitialized] 4150 | if (is_function && want_start_sal)
2023-01-10Automatic date update in version.inGDB Administrator1-1/+1
2023-01-10Set dwarf2 stash pointer earlierAlan Modra1-2/+1
This fixes a memory leak in the vanishingly rare cases (found by fuzzers of course) when something goes wrong in the save_section_vma, htab_create_alloc or alloc_trie_leaf calls before *pinfo is written. If *pinfo is not written, _bfd_dwarf2_cleanup_debug_info won't be able to free that memory. * dwarf2.c (_bfd_dwarf2_slurp_debug_info): Save stash pointer on setting up stash.
2023-01-10peXXigen.c sanity checksAlan Modra1-44/+52
Also fix a memory leak, and make some style changes. I tend to read (sizeof * x) as a multiplication of two variables, which I would not do if binutils followed the gcc coding conventions consistently (see https://gcc.gnu.org/codingconventions.html#Expressions). (sizeof *x) looks a lot better to me, or even (sizeof (*x)) which I've used here. * peXXigen.c (get_contents_sanity_check): New function. (pe_print_idata): Use it here.. (pe_print_edata): ..and here. Free data on error return. (rsrc_parse_entry): Check entry size read from file. (rsrc_parse_entries): Style fixes. (rsrc_process_section): Use bfd_malloc_and_get_section. (_bfd_XXi_final_link_postscript): Likewise.
2023-01-10Move mips_refhi_list to bfd tdataAlan Modra3-18/+31
Similar to commit c799eddb3512, but for mips-ecoff. mips-ecoff is marked obsolete, but we still allow reading of these object files in a number of mips targets. * coff-mips.c (struct mips_hi, mips_refhi_list): Delete. (mips_refhi_reloc, mips_reflo_reloc): Access mips_refhi_list in ecoff_data. * ecoff.c (_bfd_ecoff_close_and_cleanup): New function. * libecoff.h (struct mips_hi): Moved from coff-mips.c. (struct ecoff_tdata): Add mips_refhi_list. (_bfd_ecoff_close_and_cleanup): Declare.
2023-01-10Move bfd_init to bfd.cAlan Modra7-60/+56
init.c contains just one function that doesn't do much. Move it to bfd.c and give it something to do, initialising static state. So far the only initialisation is for bfd.c static variables. The idea behind reinitialising state is to see whether some set of flaky oss-fuzz crashes go away. oss-fuzz stresses binutils in ways that can't occur in reality, feeding multiple testcases into the internals of binutils. So one testcase may affect the result of the next testcase. * init.c: Delete file. Move bfd_init to.. * bfd.c (bfd_init): ..here. Init static variables. * Makefile.am (BFD32_LIBS): Remove init.lo. (BFD32_LIBS_CFILES, BFD_H_FILES): Remove init.c. * doc/local.mk: Remove mention of init.texi and init.c. * Makefile.in: Regenerate. * bfd-in2.h: Regenerate. * po/SRC-POTFILES.in: Regenerate.
2023-01-09Fix crash with C++ qualified namesTom Tromey2-0/+3
PR c++/29503 points out that something like "b->Base::member" will crash when 'b' does not have pointer type. This seems to be a simple oversight in eval_op_member. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29503 Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-01-09gdb/doc: fix @code{GDBN} -> @value{GDBN}Simon Marchi1-1/+1
Change-Id: I928d6f8d6e6bc41d8c7ddbfae8f6ae0614f4993e
2023-01-09Skip ld/pr23169 test on arm.Christophe Lyon1-3/+4
The test is already skipped on several targets (including AArch64) because it's invalid. * testsuite/ld-ifunc/ifunc.exp: Skip pr23169 on arm.
2023-01-09Fix PR18841 ifunc relocation orderingChristophe Lyon4-39/+68
In order to get the ifunc relocs properly sorted the correct class needs to be returned. The code mimics what has been done for AArch64. Fixes: FAIL: Run pr18841 with libpr18841b.so FAIL: Run pr18841 with libpr18841c.so FAIL: Run pr18841 with libpr18841bn.so (-z now) FAIL: Run pr18841 with libpr18841cn.so (-z now) bfd/ PR ld/18841 * elf32-arm.c (elf32_arm_reloc_type_class): Return reloc_class_ifunc for ifunc symbols. ld/testsuite/ * ld-arm/ifunc-12.rd: Update relocations order. * ld-arm/ifunc-3.rd: Likewise. * ld-arm/ifunc-4.rd: Likewise.
2023-01-09Updated transaltions for the gprof and binutils sub-directoriesNick Clifton5-5991/+7202
2023-01-09testsuite: add -O0 to Intel compilers if no 'optimize' option is givenTankut Baris Aktemur1-0/+41
icpx/icx give the following warning if '-g' is used without '-O'. icpx: remark: Note that use of '-g' without any optimization-level option will turn off most compiler optimizations similar to use of '-O0'; use '-Rno-debug-disables-optimization' to disable this remark [-Rdebug-disables-optimization] The warning makes dejagnu think that compilation has failed. E.g.: $ make check TESTS="gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx" ... gdb compile failed, icpx: remark: Note that use of '-g' without any optimization-level option will turn off most compiler optimizations similar to use of '-O0'; use '-Rno-debug-disables-optimization' to disable this remark [-Rdebug-disables-optimization] === gdb Summary === # of untested testcases 1 Furthermore, if no -O flag is passed, icx/icc optimize the code by default. This breaks assumptions in many GDB tests that the code is unoptimized by default. E.g.: $ make check TESTS="gdb.cp/cmpd-minsyms.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx" ... FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::a() const' FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::b() volatile' FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::c() const volatile' FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator == FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator==(GDB<int> const&) FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<char>::harder(char) FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::harder(int) FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at "int GDB<char>::even_harder<int>(char)" FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::simple() === gdb Summary === # of expected passes 1 # of unexpected failures 9 To fix both problems, pass the -O0 flag explicitly, if no optimization option is given. With this patch we get, e.g.: $ make check TESTS="gdb.cp/cmpd-minsyms.exp gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx" ... === gdb Summary === # of expected passes 19 # of known failures 1 Approved-By: Tom Tromey <tom@tromey.com>
2023-01-09testsuite: handle icc and icpc deprecated remarksNils-Christian Kempke1-7/+30
Starting with icc/icpc version 2021.7.0 and higher both compilers emit a deprecation remark when used. E.g. >> icc --version icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated and will be removed from product release in the second half of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward. Please transition to use this compiler. Use '-diag-disable=10441' to disable this message. icc (ICC) 2021.7.0 20220713 Copyright (C) 1985-2022 Intel Corporation. All rights reserved. >> icpc --version icpc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated ... icpc (ICC) 2021.7.0 20220720 Copyright (C) 1985-2022 Intel Corporation. All rights reserved. As the testsuite compile fails when unexpected output by the compiler is seen this change in the compiler breaks all existing icc and icpc tests. This patch makes the gdb testsuite more forgiving by a) allowing the output of the remark when trying to figure out the compiler version and by b) adding '-diag-disable=10441' to the compile command whenever gdb_compile is called without the intention to detect the compiler. Approved-By: Tom Tromey <tom@tromey.com>
2023-01-09Automatic date update in version.inGDB Administrator1-1/+1
2023-01-08PR29972, inconsistent format specification in singular formAlan Modra1-1/+1
PR 29972 * readelf.c (process_dynamic_section): Correct format string.
2023-01-08Automatic date update in version.inGDB Administrator1-1/+1
2023-01-07Automatic date update in version.inGDB Administrator1-1/+1
2023-01-06sframe: fix the defined SFRAME_FRE_TYPE_*_LIMIT constantsIndu Bhagat4-12/+17
An earlier commit 3f107464 defined the SFRAME_FRE_TYPE_*_LIMIT constants. These constants are used (by gas and libsframe) to pick an SFrame FRE type based on the function size. Those constants, however, were buggy, causing the generated SFrame sections to be bloated as SFRAME_FRE_TYPE_ADDR2/SFRAME_FRE_TYPE_ADDR4 got chosen more often than necessary. gas/ * sframe-opt.c (sframe_estimate_size_before_relax): Use typecast. (sframe_convert_frag): Likewise. libsframe/ * sframe.c (sframe_calc_fre_type): Use a more appropriate type for argument. Adjust the check for SFRAME_FRE_TYPE_ADDR4_LIMIT to keep it warning-free but meaningful. include/ * sframe-api.h (sframe_calc_fre_type): Use a more appropriate type for the argument. * sframe.h (SFRAME_FRE_TYPE_ADDR1_LIMIT): Correct the constant. (SFRAME_FRE_TYPE_ADDR2_LIMIT): Likewise. (SFRAME_FRE_TYPE_ADDR4_LIMIT): Likewise.
generated by cgit v1.1 at 2024-11-19 11:39:55 +0000