gdb: Move DJGPP/go32 bits to their own tdep file
Commit Message
I posit that this makes them easier to find.
The other day while working on the wchar_t patch, I had a bit of
trouble finding the DJGPP/go32 tdep bits. My initial reaction was
looking for a go32-specific tdep file, but there's none.
Confirmed that a --host=i586-pc-msdosdjgpp gdb still builds
successfully and includes the i386-go32-tdep.o object.
Confirmed that an --enable-targets=all build of gdb on x86-64
GNU/Linux includes the djgpp bits too.
OK to apply?
gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <palves@redhat.com>
* Makefile.in (ALL_TARGET_OBS): Add i386-go32-tdep.o.
* configure.tgt: Handle i[34567]86-*-go32* and
i[34567]86-*-msdosdjgpp*.
* i386-tdep.c (i386_svr4_reg_to_regnum):
Make extern.
(i386_go32_init_abi, i386_coff_osabi_sniffer): Moved to
i386-go32-tdep.c.
(_initialize_i386_tdep): DJGPP bits moved to i386-go32-tdep.c.
* i386-go32-tdep.c: New file.
* i386-tdep.h (tdesc_i386_mmx, i386_svr4_reg_to_regnum): New
declarations.
---
gdb/Makefile.in | 1 +
gdb/configure.tgt | 4 +++
gdb/i386-go32-tdep.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++
gdb/i386-tdep.c | 44 +-------------------------------
gdb/i386-tdep.h | 5 ++++
5 files changed, 83 insertions(+), 43 deletions(-)
create mode 100644 gdb/i386-go32-tdep.c
Comments
> From: Pedro Alves <palves@redhat.com>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Wed, 12 Apr 2017 14:31:15 +0100
>
> I posit that this makes them easier to find.
>
> The other day while working on the wchar_t patch, I had a bit of
> trouble finding the DJGPP/go32 tdep bits. My initial reaction was
> looking for a go32-specific tdep file, but there's none.
Thanks, but why single out go32? The comment in i386-tdep.c says:
/* There are a few i386 architecture variants that differ only
slightly from the generic i386 target. For now, we don't give them
their own source file, but include them here. As a consequence,
they'll always be included. */
If we are going to have a separate tdep file for such architectures,
let's do it for SVR4 as well.
P.S. How come functions and other symbols are looked for via file
names, and not via TAGS?
On 04/12/2017 02:47 PM, Eli Zaretskii wrote:
>> From: Pedro Alves <palves@redhat.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>
>> Date: Wed, 12 Apr 2017 14:31:15 +0100
>>
>> I posit that this makes them easier to find.
>>
>> The other day while working on the wchar_t patch, I had a bit of
>> trouble finding the DJGPP/go32 tdep bits. My initial reaction was
>> looking for a go32-specific tdep file, but there's none.
>
> Thanks, but why single out go32?
Because incremental progress.
> The comment in i386-tdep.c says:
>
> /* There are a few i386 architecture variants that differ only
> slightly from the generic i386 target. For now, we don't give them
> their own source file, but include them here. As a consequence,
> they'll always be included. */
>
> If we are going to have a separate tdep file for such architectures,
> let's do it for SVR4 as well.
That can be done, but I don't see why it has to be in the same patch?
> P.S. How come functions and other symbols are looked for via file
> names, and not via TAGS?
>
I don't know.
Thanks,
Pedro Alves
On 04/12/2017 03:07 PM, Pedro Alves wrote:
> On 04/12/2017 02:47 PM, Eli Zaretskii wrote:
>>> From: Pedro Alves <palves@redhat.com>
>>> Cc: Eli Zaretskii <eliz@gnu.org>
>>> Date: Wed, 12 Apr 2017 14:31:15 +0100
>>>
>>> I posit that this makes them easier to find.
>>>
>>> The other day while working on the wchar_t patch, I had a bit of
>>> trouble finding the DJGPP/go32 tdep bits. My initial reaction was
>>> looking for a go32-specific tdep file, but there's none.
>>
>> Thanks, but why single out go32?
>
> Because incremental progress.
Specifically, the "trouble finding djgpp bits" I'm referring to
happened after you pointed me that djgpp needed a tweak too:
https://sourceware.org/ml/gdb-patches/2017-03/msg00538.html
At first, I didn't see a tdep file and so I thought that I'd have
to add one, and maybe come up with a djgpp arch sniffer. It took
me a few minutes to realize that we already have go32-specific
tdep bits in the generic i386 file. So that's my only
motivation -- exactly to make it easier to spot the djgpp bits
quicker. There's no other rationale behind this. If I'll have to
go do more things to other ports to get this in, I'm afraid I'll
just drop the patch, because _I_ will have learned about them and
know next time where to look.
Thanks,
Pedro Alves
> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Wed, 12 Apr 2017 15:07:02 +0100
>
> > The comment in i386-tdep.c says:
> >
> > /* There are a few i386 architecture variants that differ only
> > slightly from the generic i386 target. For now, we don't give them
> > their own source file, but include them here. As a consequence,
> > they'll always be included. */
> >
> > If we are going to have a separate tdep file for such architectures,
> > let's do it for SVR4 as well.
>
> That can be done, but I don't see why it has to be in the same patch?
It doesn't.
> > P.S. How come functions and other symbols are looked for via file
> > names, and not via TAGS?
> >
>
> I don't know.
Got it.
Thanks.
> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Wed, 12 Apr 2017 15:25:56 +0100
>
> >> Thanks, but why single out go32?
> >
> > Because incremental progress.
>
> Specifically, the "trouble finding djgpp bits" I'm referring to
> happened after you pointed me that djgpp needed a tweak too:
>
> https://sourceware.org/ml/gdb-patches/2017-03/msg00538.html
>
> At first, I didn't see a tdep file and so I thought that I'd have
> to add one, and maybe come up with a djgpp arch sniffer. It took
> me a few minutes to realize that we already have go32-specific
> tdep bits in the generic i386 file. So that's my only
> motivation -- exactly to make it easier to spot the djgpp bits
> quicker. There's no other rationale behind this. If I'll have to
> go do more things to other ports to get this in, I'm afraid I'll
> just drop the patch, because _I_ will have learned about them and
> know next time where to look.
It's fine with me if you decide to make only that change. I just
think that if you had this difficulty with go32 bits, someone else
might have the same difficulty with SVR4 bits. That's why I wrote
what I wrote.
On 04/12/2017 03:42 PM, Eli Zaretskii wrote:
>> Cc: gdb-patches@sourceware.org
>> From: Pedro Alves <palves@redhat.com>
>> Date: Wed, 12 Apr 2017 15:07:02 +0100
>>
>>> The comment in i386-tdep.c says:
>>>
>>> /* There are a few i386 architecture variants that differ only
>>> slightly from the generic i386 target. For now, we don't give them
>>> their own source file, but include them here. As a consequence,
>>> they'll always be included. */
>>>
>>> If we are going to have a separate tdep file for such architectures,
>>> let's do it for SVR4 as well.
>>
>> That can be done, but I don't see why it has to be in the same patch?
>
> It doesn't.
So to be clear, are you OK with the patch as is?
Thanks,
Pedro Alves
On 04/12/2017 03:45 PM, Eli Zaretskii wrote:
> It's fine with me if you decide to make only that change. I just
> think that if you had this difficulty with go32 bits, someone else
> might have the same difficulty with SVR4 bits. That's why I wrote
> what I wrote.
Hmm, actually, the SVR4 bits are likely useless by now? It seems to me
that the only way to activate them is to manually do "set osabi SVR4".
At least according to a grep by GDB_OSABI_SVR4:
defs.h: GDB_OSABI_SVR4,
i386-tdep.c: gdbarch_register_osabi (bfd_arch_i386, 0, GDB_OSABI_SVR4,
I.e., unlike most other ports, there's no osabi sniffer to auto-detect
SVR4.
Grepping for i386_svr4_init_abi, we see that Solaris is the only other
SVR4-like port that reuses the function:
i386-tdep.c:4474:i386_svr4_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
i386-tdep.c:9093: i386_svr4_init_abi);
i386-tdep.h:433:extern void i386_svr4_init_abi (struct gdbarch_info, struct gdbarch *);
i386-sol2-tdep.c:109: i386_svr4_init_abi (info, gdbarch);
So maybe we should drop GDB_OSABI_SVR4, and inline/move the i386_svr4_init_abi
function to i386-sol2-tdep.c.
Thanks,
Pedro Alves
> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Wed, 12 Apr 2017 15:45:59 +0100
>
> On 04/12/2017 03:42 PM, Eli Zaretskii wrote:
> >> Cc: gdb-patches@sourceware.org
> >> From: Pedro Alves <palves@redhat.com>
> >> Date: Wed, 12 Apr 2017 15:07:02 +0100
> >>
> >>> The comment in i386-tdep.c says:
> >>>
> >>> /* There are a few i386 architecture variants that differ only
> >>> slightly from the generic i386 target. For now, we don't give them
> >>> their own source file, but include them here. As a consequence,
> >>> they'll always be included. */
> >>>
> >>> If we are going to have a separate tdep file for such architectures,
> >>> let's do it for SVR4 as well.
> >>
> >> That can be done, but I don't see why it has to be in the same patch?
> >
> > It doesn't.
>
> So to be clear, are you OK with the patch as is?
Yes. Sorry if it wasn't clear.
On 04/12/2017 03:58 PM, Eli Zaretskii wrote:
>> So to be clear, are you OK with the patch as is?
>
> Yes. Sorry if it wasn't clear.
No problem. I've pushed it in. Thanks!
On 04/12/2017 03:57 PM, Pedro Alves wrote:
> So maybe we should drop GDB_OSABI_SVR4, and inline/move the i386_svr4_init_abi
> function to i386-sol2-tdep.c.
Darn, I couldn't resist looking further into this. :-P I've moved it to
a separate thread.
Thanks,
Pedro Alves
@@ -810,6 +810,7 @@ ALL_TARGET_OBS = \
i386-dicos-tdep.o \
i386-fbsd-tdep.o \
i386-gnu-tdep.o \
+ i386-go32-tdep.o \
i386-linux-tdep.o \
i386-nbsd-tdep.o \
i386-nto-tdep.o \
@@ -253,6 +253,10 @@ i[34567]86-*-mingw32*)
windows-tdep.o"
build_gdbserver=yes
;;
+i[34567]86-*-go32* | i[34567]86-*-msdosdjgpp*)
+ # Target: i386 running DJGPP/go32.
+ gdb_target_obs="i386-tdep.o i387-tdep.o i386-go32-tdep.o"
+ ;;
i[34567]86-*-*)
# Target: i386
gdb_target_obs="i386-tdep.o i387-tdep.o"
new file mode 100644
@@ -0,0 +1,72 @@
+/* Target-dependent code for DJGPP/i386.
+
+ Copyright (C) 1988-2017 Free Software Foundation, Inc.
+
+ This file is part of GDB.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+#include "defs.h"
+#include "i386-tdep.h"
+#include "target-descriptions.h"
+#include "osabi.h"
+
+static void
+i386_go32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+ struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+
+ /* DJGPP doesn't have any special frames for signal handlers. */
+ tdep->sigtramp_p = NULL;
+
+ tdep->jb_pc_offset = 36;
+
+ /* DJGPP does not support the SSE registers. */
+ if (!tdesc_has_registers (info.target_desc))
+ tdep->tdesc = tdesc_i386_mmx;
+
+ /* Native compiler is GCC, which uses the SVR4 register numbering
+ even in COFF and STABS. See the comment in i386_gdbarch_init,
+ before the calls to set_gdbarch_stab_reg_to_regnum and
+ set_gdbarch_sdb_reg_to_regnum. */
+ set_gdbarch_stab_reg_to_regnum (gdbarch, i386_svr4_reg_to_regnum);
+ set_gdbarch_sdb_reg_to_regnum (gdbarch, i386_svr4_reg_to_regnum);
+
+ set_gdbarch_has_dos_based_file_system (gdbarch, 1);
+
+ set_gdbarch_wchar_bit (gdbarch, 16);
+ set_gdbarch_wchar_signed (gdbarch, 0);
+}
+
+
+static enum gdb_osabi
+i386_coff_osabi_sniffer (bfd *abfd)
+{
+ if (strcmp (bfd_get_target (abfd), "coff-go32-exe") == 0
+ || strcmp (bfd_get_target (abfd), "coff-go32") == 0)
+ return GDB_OSABI_GO32;
+
+ return GDB_OSABI_UNKNOWN;
+}
+
+
+void
+_initialize_i386_go32_tdep ()
+{
+ gdbarch_register_osabi_sniffer (bfd_arch_i386, bfd_target_coff_flavour,
+ i386_coff_osabi_sniffer);
+
+ gdbarch_register_osabi (bfd_arch_i386, 0, GDB_OSABI_GO32,
+ i386_go32_init_abi);
+}
@@ -573,7 +573,7 @@ i386_svr4_dwarf_reg_to_regnum (struct gdbarch *gdbarch, int reg)
/* Wrapper on i386_svr4_dwarf_reg_to_regnum to return
num_regs + num_pseudo_regs for other debug formats. */
-static int
+int
i386_svr4_reg_to_regnum (struct gdbarch *gdbarch, int reg)
{
int regnum = i386_svr4_dwarf_reg_to_regnum (gdbarch, reg);
@@ -4487,34 +4487,6 @@ i386_svr4_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
tdep->jb_pc_offset = 20;
}
-/* DJGPP. */
-
-static void
-i386_go32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
-{
- struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
-
- /* DJGPP doesn't have any special frames for signal handlers. */
- tdep->sigtramp_p = NULL;
-
- tdep->jb_pc_offset = 36;
-
- /* DJGPP does not support the SSE registers. */
- if (! tdesc_has_registers (info.target_desc))
- tdep->tdesc = tdesc_i386_mmx;
-
- /* Native compiler is GCC, which uses the SVR4 register numbering
- even in COFF and STABS. See the comment in i386_gdbarch_init,
- before the calls to set_gdbarch_stab_reg_to_regnum and
- set_gdbarch_sdb_reg_to_regnum. */
- set_gdbarch_stab_reg_to_regnum (gdbarch, i386_svr4_reg_to_regnum);
- set_gdbarch_sdb_reg_to_regnum (gdbarch, i386_svr4_reg_to_regnum);
-
- set_gdbarch_has_dos_based_file_system (gdbarch, 1);
-
- set_gdbarch_wchar_bit (gdbarch, 16);
- set_gdbarch_wchar_signed (gdbarch, 0);
-}
/* i386 register groups. In addition to the normal groups, add "mmx"
@@ -8739,15 +8711,6 @@ i386_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
return gdbarch;
}
-static enum gdb_osabi
-i386_coff_osabi_sniffer (bfd *abfd)
-{
- if (strcmp (bfd_get_target (abfd), "coff-go32-exe") == 0
- || strcmp (bfd_get_target (abfd), "coff-go32") == 0)
- return GDB_OSABI_GO32;
-
- return GDB_OSABI_UNKNOWN;
-}
/* Return the target description for a specified XSAVE feature mask. */
@@ -9085,13 +9048,8 @@ Show Intel Memory Protection Extensions specific variables."),
in the bound table.",
&mpx_set_cmdlist);
- gdbarch_register_osabi_sniffer (bfd_arch_i386, bfd_target_coff_flavour,
- i386_coff_osabi_sniffer);
-
gdbarch_register_osabi (bfd_arch_i386, 0, GDB_OSABI_SVR4,
i386_svr4_init_abi);
- gdbarch_register_osabi (bfd_arch_i386, 0, GDB_OSABI_GO32,
- i386_go32_init_abi);
/* Initialize the i386-specific register groups. */
i386_init_reggroups ();
@@ -340,6 +340,7 @@ enum record_i386_regnum
#define I386_MAX_REGISTER_SIZE 64
extern struct target_desc *tdesc_i386;
+extern struct target_desc *tdesc_i386_mmx;
/* Types for i386-specific registers. */
extern struct type *i387_ext_type (struct gdbarch *gdbarch);
@@ -432,6 +433,10 @@ extern void i386_elf_init_abi (struct gdbarch_info, struct gdbarch *);
/* Initialize a SVR4 architecture variant. */
extern void i386_svr4_init_abi (struct gdbarch_info, struct gdbarch *);
+/* Convert SVR4 register number REG to the appropriate register number
+ used by GDB. */
+extern int i386_svr4_reg_to_regnum (struct gdbarch *gdbarch, int reg);
+
extern int i386_process_record (struct gdbarch *gdbarch,
struct regcache *regcache, CORE_ADDR addr);
extern const struct target_desc *i386_target_description (uint64_t xcr0);