112966 Commits

Author SHA1 Message Date
f56532cc17 gas/RISC-V: adjust assembler for opcode table re-ordering
PR gas/29940

With the single-operand JAL entry now sitting ahead of the two-operand
one, the parsing of a two-operand insn would first try to parse an 'a'-
style operand, resulting in the insertion of bogus (and otherwise
unused) undefined symbols in the symbol table, having register names.
Since 'a' is used as 1st operand only with J and JAL, and since JAL is
the only insn _also_ allowing for a register as 1st operand (and then
there being a 2nd one), special case this parsing aspect right there.

Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-01-11 10:31:43 +01:00
a95fb4e346 Tidy some global bfd state used by gas
* subsegs.c (subsegs_end): Clear abs and und userdata.
2023-01-11 19:05:26 +10:30
da1f81c128 now_seg after closing output file
now_seg, a pointer into the output file sections, isn't valid after
the output file is closed.  gas doesn't and shouldn't use now_seg
after this point of course, but let's be safe.

	* output-file.c (output_file_close): Clear now_seg and now_subseg.
2023-01-11 15:31:06 +10:30
6647169da4 Automatic date update in version.in 2023-01-11 00:00:23 +00:00
066620dcfb Fix bug in 'say_where' transform
The patch to change say_where into a method introduced a bug.  This
patch fixes it.
2023-01-10 16:36:48 -07:00
7697bc6523 gas: Restore tc_pe_dwarf2_emit_offset for pe-aarch64
Restores tc_pe_dwarf2_emit_offset in tc-aarch64.c, which is needed to
make sure that DWARF offsets are encoded correctly (they're secrels in
COFF). There were remnants of this there before, but they were removed
by Jedidiah's original patch - presumably because we didn't yet have
.secrel32.
2023-01-10 23:30:52 +00:00
16fea92ccd Add aarch64-w64-mingw32 target
This adds a mingw target for aarch64, including windres and dlltool.

Note that the old value of jmp_aarch64_bytes was wrong, and this does
the same thing as MSVC does.
2023-01-10 23:30:49 +00:00
528e4f463f Add .secrel32 for pe-aarch64
Adds the .secrel32 pseudo-directive and its corresponding relocation.
2023-01-10 23:30:46 +00:00
b152649d51 Add pe-aarch64 relocations
This adds the remaining pe-aarch64 relocations, and gets them working.
It also brings in the constant directives from ELF, as otherwise .word
would be 2 rather than 4 bytes, and .xword and .dword wouldn't be
defined.
2023-01-10 23:30:44 +00:00
5093b5a5e7 Fix size of external_reloc for pe-aarch64
This patch series finishes off the work by Jedidiah Thompson, and adds
support for creating aarch64 PE images.

This should be essentially complete: I've used this to create a "hello
world" Windows program in asm, and (with GCC patches) a UEFI program in
C. I think the only things missing are the .secidx relocation, which is
needed for PDBs, and the SEH pseudos used for C++ exceptions.

This first patch fixes the size of RELSZ; I'm not sure why it was 14 in
the first place. This is the size of the "Base Relocation Block" in
https://learn.microsoft.com/en-us/windows/win32/debug/pe-format, and
AFAIK should be 10 for everything.
2023-01-10 23:30:42 +00:00
38190b2f01 gdb/dwarf2: Fix 'rw_pieced_value' for values casted to different type.
The 'rw_pieced_value' function is executed when fetching a (lazy)
variable described by 'DW_OP_piece' or 'DW_OP_bit_piece'.  The
function checks the 'type' and 'enclosing_type' fields of the value
for identity.

  * The 'type' field describes the type of a value.
  * In most cases, the 'enclosing_type' field is identical to the
    'type' field.
  * Scenarios where the 'type' and 'enclosing_type' of an object
    differ are described in 'gdb/value.c'.  Possible cases are:
    * If a value represents a C++ object, then the 'type' field
      gives the object's compile-time type.  If the object actually
      belongs to some class derived from `type', perhaps with other
      base classes and additional members, then `type' is just a
      subobject of the real thing, and the full object is probably
      larger than `type' would suggest.
    * If 'type' is a dynamic class (i.e. one with a vtable), then GDB
      can actually determine the object's run-time type by looking at
      the run-time type information in the vtable.  GDB may then elect
      to read the entire object.
    * If the user casts a variable to a different type
      (e.g. 'print (<type> []) <variable>'), the value's type is
      updated before reading the value.

If a lazy value is fetched, GDB allocates space based on the enclosing
type's length and typically reads the 'full' object.  This is not
implemented for pieced values and causes an internal error if 'type'
and 'enclosing_type' of a value are not identical.

However, GDB can read the value based on its type.  Thus, this patch
fixes the previously mentioned cases by removing the check for identity.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28605

gdb/ChangeLog:
2022-04-13  Stephan Rohr  <stephan.rohr@intel.com>

	* dwarf2/loc.c (rw_pieced_value): Fix check on 'type' and
	'enlcosing_type' when reading pieced value 'v'.

gdb/testsuite/ChangeLog:
2022-04-13  Stephan Rohr  <stephan.rohr@intel.com>

	* gdb.dwarf2/shortpiece.exp: Added test cases.
2023-01-10 14:26:32 -07:00
7987c4636a Convert say_where to method on code_breakpoint
'say_where' is only useful (and only called for) code breakpoints, so
convert it to be a protected method on code_breakpoint.
2023-01-10 14:09:32 -07:00
8ec0b0b5df gdb/doc: use @value{GDBP} in some spots
Examples are supposed to use @value{GDBP} instead of the literal "(gdb)"
(many of them already do).  Update a bunch of spots where it wasn't the
case.

Change-Id: I601adaad61fd277a5fceea1759e49cede72e456d
2023-01-10 10:11:48 -05:00
01c470037c gdb/doc: use @value{GDBN} in some spots
Change some spots to use "@value{GDBN}" instead of just "GDB".

Change-Id: I3fc26438e603538271cf33e4d148be5fda9ece7e
2023-01-10 10:11:48 -05:00
cc81f07b80 gdb/doc: some whitespace fixes
For consistency, replace tabs with spaces in all gdb.texinfo menus.

Change-Id: I0801a72cf82a8afe49ec842244f42d30719634ce
2023-01-10 10:11:48 -05:00
aefebe82dc IBM zSystems: Fix offset relative to static TLS
For local exec TLS relocations of the form foo@NTPOFF+x the addend was
ignored.

bfd/ChangeLog:

	* elf32-s390.c (elf_s390_relocate_section): Honor addend for
	R_390_TLS_LE32.
	* elf64-s390.c (elf_s390_relocate_section): Honor addend for
	R_390_TLS_LE64.

ld/ChangeLog:

	* testsuite/ld-s390/reloctlsle-1.d: New test.
	* testsuite/ld-s390/reloctlsle-1.s: New test.
2023-01-10 14:34:16 +01:00
18737d1479 PR 29981 references to init.texi 2023-01-10 23:05:31 +10:30
56b3aa508c Re: Move bfd_init to bfd.c
Commit b1c95bc4dd73 resulted in
...bfd.texi:246: @include: could not find init.texi
which went unnoticed due to not building in a clean directory.

This fixes the problem by moving bfd_init earlier, giving it a
doc node, and stitching the nodes back together.

	* bfd.c (bfd_init): Move earlier.  Give it a doc inode.
	Adjust other inodes to suit.
	* doc/bfd.texi: Don't include init.texi.  Adjust nodes to suit.
2023-01-10 20:42:24 +10:30
fd95c73ef5 sim: disable recursive make in (most) subdirs
Now that all (other than ppc) build in the top-level, we can disable
the recursive make calls to them.  This speeds things up nicely.
2023-01-10 01:22:00 -05:00
b014c9b087 sim: common: move test-hw-events to top-level build
This is an internal developer target that isn't normally compiled,
but it can still be occasionally useful.  Move it to the top-level
build so we can kill off common/Make-common.in.
2023-01-10 01:15:29 -05:00
b36a89d135 sim: move arch-specific file compilation of common/ files to top-level 2023-01-10 01:15:29 -05:00
8f5fc30fcf sim: v850: move arch-specific file compilation to top-level
The arch-specific compiler flags are duplicated, but they'll be cleaned
up once we move all subdir compiles to the top-level.
2023-01-10 01:15:29 -05:00
d667f7b30a sim: sh: move arch-specific file compilation to top-level 2023-01-10 01:15:28 -05:00
3e3e7217b0 sim: rx: move arch-specific file compilation to top-level
The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.
2023-01-10 01:15:28 -05:00
0db0b664a6 sim: rl78: move arch-specific file compilation to top-level 2023-01-10 01:15:28 -05:00
e7699de502 sim: riscv: move arch-specific file compilation to top-level
The arch-specific compiler flags are duplicated, but they'll be cleaned
up once we move all subdir compiles to the top-level.
2023-01-10 01:15:28 -05:00
51bc8f3a16 sim: pru: move arch-specific file compilation to top-level 2023-01-10 01:15:28 -05:00
b7bd5fe99b sim: or1k: move arch-specific file compilation to top-level
The arch-specific compiler flags are duplicated, but they'll be cleaned
up once we move all subdir compiles to the top-level.
2023-01-10 01:15:28 -05:00
4fff443a11 sim: msp430: move arch-specific file compilation to top-level 2023-01-10 01:15:28 -05:00
ae0411a485 sim: moxie: move arch-specific file compilation to top-level
The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.
2023-01-10 01:15:28 -05:00
63a9d59e88 sim: mn10300: move arch-specific file compilation to top-level
The arch-specific compiler flags are duplicated, but they'll be cleaned
up once we move all subdir compiles to the top-level.
2023-01-10 01:15:28 -05:00
1546cb4540 sim: mips: move arch-specific file compilation to top-level
The arch-specific compiler flags are duplicated, but they'll be cleaned
up once we move all subdir compiles to the top-level.
2023-01-10 01:15:28 -05:00
b7375a2dda sim: microblaze: move arch-specific file compilation to top-level 2023-01-10 01:15:28 -05:00
28ae9bed3d sim: mcore: move arch-specific file compilation to top-level 2023-01-10 01:15:28 -05:00
5a71cd470f sim: m68hc11: move arch-specific file compilation to top-level
The arch-specific compiler flags are duplicated, but they'll be cleaned
up once we move all subdir compiles to the top-level.
2023-01-10 01:15:28 -05:00
9b5a17d2be sim: m32r: move arch-specific file compilation to top-level 2023-01-10 01:15:28 -05:00
cd7aa21771 sim: m32c: move arch-specific file compilation to top-level
The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.
2023-01-10 01:15:28 -05:00
2d3b0c959d sim: lm32: move arch-specific file compilation to top-level 2023-01-10 01:15:28 -05:00
d2c06f6bcd sim: iq2000: move arch-specific file compilation to top-level 2023-01-10 01:15:28 -05:00
dced2faff5 sim: h8300: move arch-specific file compilation to top-level 2023-01-10 01:15:28 -05:00
abc4c2173c sim: ft32: move arch-specific file compilation to top-level 2023-01-10 01:15:28 -05:00
5ea1eaea7a sim: frv: move arch-specific file compilation to top-level
The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.
2023-01-10 01:15:28 -05:00
8ba643c31e sim: example-synacor: move arch-specific file compilation to top-level 2023-01-10 01:15:28 -05:00
304195bcf8 sim: erc32: move arch-specific file compilation to top-level
The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.
2023-01-10 01:15:28 -05:00
2206990476 sim: d10v: move arch-specific file compilation to top-level 2023-01-10 01:15:27 -05:00
71fa869293 sim: cris: move arch-specific file compilation to top-level 2023-01-10 01:15:27 -05:00
df4b07f4b7 sim: cr16: move arch-specific file compilation to top-level 2023-01-10 01:15:27 -05:00
a8e175e578 sim: bfin: move arch-specific file compilation to top-level
The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.
2023-01-10 01:15:27 -05:00
75015a129f sim: bpf: move arch-specific file compilation to top-level
We can drop the arch-specific rules from the subdir as they're no
longer used.
2023-01-10 01:15:27 -05:00
98331de786 sim: avr: move arch-specific file compilation to top-level 2023-01-10 01:15:27 -05:00