Re: [PATCH 1/4] Split up s390-linux-tdep.c into two files

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Phillip Rudo wrote:

> I think it is best when we defer the question whether the kernel target should
> use s390-linux-tdep till after the split is final. Then we have a stable base
> we can use.

Sure.
 
> Is there anything in s390-tdep.c left you think that should be moved?
> Otherwise ...

As discussed earlier, I think the ABI-related routines are fine to move
to the generic part, since they explicitly check tdep->abi.  Given that,
I think the only stuff that really needs to be Linux-specific is the
syscall handling (including interrupted system call restart), the register
sets, and the signal frame handling.  That would be about these routines:

s390_write_pc (struct regcache *regcache, CORE_ADDR pc)
s390_supply_tdb_regset (const struct regset *regset, struct regcache *regcache,
s390_iterate_over_regset_sections (struct gdbarch *gdbarch,
s390_core_read_description (struct gdbarch *gdbarch,
s390_sigtramp_frame_unwind_cache (struct frame_info *this_frame,
s390_sigtramp_frame_this_id (struct frame_info *this_frame,
s390_sigtramp_frame_prev_register (struct frame_info *this_frame,
s390_sigtramp_frame_sniffer (const struct frame_unwind *self,
s390_linux_get_syscall_number (struct gdbarch *gdbarch,
s390_all_but_pc_registers_record (struct regcache *regcache)
s390_canonicalize_syscall (int syscall, enum s390_abi_kind abi)
s390_linux_syscall_record (struct regcache *regcache, LONGEST syscall_native)
s390_linux_record_signal (struct gdbarch *gdbarch, struct regcache *regcache,
s390_init_linux_record_tdep (struct linux_record_tdep *record_tdep,

Everything else can move to s390-tdep.c

> ... i'll move the regsets and s390_register_call_saved to s390-linux-tdep. The
> way the latter currently is implemented doesn't support any other OS than Linux.

s390_register_call_saved is really just one of the ABI routines and can stay
with the rest of them.  If we ever need to support different ABIs, we can
always extend the value set of tdep->abi.

> My plan is to add the usage of OSABI on top of the split as is (with the small
> changes described above). This makes it easier to find bugs i might introduce
> which would otherwise be cloaked by the split. Any rejections?

Hmm.  If you want to split this, I'd prefer if you were to first add the OSABI
routines *while keeping everything in one file* and then split the files.
(The newly added OSABI stuff will remain in s390-linux-tdep.c anyway).

> My problem aren't the tdep->have_* fields but the corresponding variables
> defined in s390_gdbarch_init. With them all there are dependencies all over the
> function.

It looks to me that there's a first part that *sets* those values, and then
a couple of later uses that determine the pseudo register numbers.  That latter
part can use the tdep->have_ flags instead (they are already set at this point)
and can move to the generic file.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com