From: Yao Qi <qiyaoltc@gmail.com>
To: "Maciej W. Rozycki" <macro@imgtec.com>
Cc: <binutils@sourceware.org>, <gdb-patches@sourceware.org>
Subject: Re: [PATCH 2/6] Delegate opcodes to select disassembler in GDB
Date: Fri, 07 Jul 2017 16:41:00 -0000 [thread overview]
Message-ID: <867ezk5hea.fsf@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1707060024070.3339@tp.orcam.me.uk> (Maciej W. Rozycki's message of "Thu, 6 Jul 2017 00:53:18 +0100")
"Maciej W. Rozycki" <macro@imgtec.com> writes:
> I can see the assumption from the assertion itself, but what is its
> purpose?
>
The purpose of this assert is to check that the disassemble_info passed
to opcodes is correctly got from the executable.
> Normally you place an assertion in code to guard against a case that is
> not handled (correctly) and if let through it would lead execution to go
> astray, e.g. because it is a new complicated feature we have not yet got
> to implementing or because it is a case we think that will never happen,
> and code that follows has assumptions that will not be met.
>
> So if you say that you can remove the assertion with no adverse effect on
> processing, then I think it should not have been placed there in the first
> place.
>
> Anyway, if you look at code in `gdb_print_insn_mips', then you'll find
> this comment:
>
> /* FIXME: cagney/2003-06-26: Is this even necessary? The
> disassembler needs to be able to locally determine the ISA, and
> not rely on GDB. Otherwize the stand-alone 'objdump -d' will not
> work. */
>
Yes, that is the point of my patch series.
> and it is indeed the case that `objdump' handles this correctly without
> the need to switch away from the BFD selected for the binary being
> handled. However in GDB we have this problem that we do not pass the
> symbol table down to libopcodes for the disassembler, and in the case of
> the MIPS target it is the symbol table that carries information about
> which functions contain regular MIPS code, MIPS16 code and microMIPS code
> respectively.
>
> Lacking symbol information we resort to this hack of overriding the BFD
> for the purpose of disassembly only, and this has the adverse effect of
> getting instruction subsetting wrong: the `bfd_mach_mips16' and
> `bfd_mach_mips_micromips' BFDs always choose the maximum instruction set
> supported possible whereas the binary handled may only support a subset
> (or worse yet an alternative set), as indicated by the original BFD
> selected. This in turn may confuse and mislead the person running a debug
> session into thinking code disassembled is not the problem they are after.
>
> Do you think it would be possible as a part of your disassembler rework
> to make the symbol table available to libopcodes? Then the hack currently
> present in `gdb_print_insn_mips' could go. I remember looking into it a
> while ago and concluding it would be somewhat tricky because the symbol
> table format expected by libopcodes is not the same that we use in
> GDB.
We can pass the symbol table to opcodes, so it can choose the right
disassembler. However, current GDB uses both symbol and address to
determine some address is in a MIPS16 or microMIPS function (done by
mips_pc_is_mips16, mips_pc_is_micromips). If we want to use symbol
table to tell the address is in microMIPS or MIPS16, and GDB can't find
a symbol for a given address, I suppose we need to create a fake
symbol, and pass it to disassembler. Why don't we teach GDB
unconditionally create a fake symbol with the right bits set in order to
meet the check in mips-dis.c:is_compressed_mode_p?
arm-tdep.c:gdb_print_insn_arm has already do so to disassemble Thumb
instructions.
What do you think of the patch below? IMO, change in
is_compressed_mode_p fixes a bug on usage of info->num_symbols vs.
info->symtab_size. I can't test this patch.
--
Yao (齐尧)
diff --git a/gdb/mips-tdep.c b/gdb/mips-tdep.c
index c1800e4..b848015 100644
--- a/gdb/mips-tdep.c
+++ b/gdb/mips-tdep.c
@@ -7007,14 +7007,31 @@ gdb_print_insn_mips (bfd_vma memaddr, struct disassemble_info *info)
disassembler needs to be able to locally determine the ISA, and
not rely on GDB. Otherwize the stand-alone 'objdump -d' will not
work. */
- if (mips_pc_is_mips16 (gdbarch, memaddr))
- info->mach = bfd_mach_mips16;
- else if (mips_pc_is_micromips (gdbarch, memaddr))
- info->mach = bfd_mach_mips_micromips;
-
- /* Round down the instruction address to the appropriate boundary. */
- memaddr &= (info->mach == bfd_mach_mips16
- || info->mach == bfd_mach_mips_micromips) ? ~1 : ~3;
+ if (mips_pc_is_mips16 (gdbarch, memaddr)
+ || mips_pc_is_micromips (gdbarch, memaddr))
+ {
+ static asymbol asym;
+ static asymbol *asymp = &asym;
+
+ /* Create a fake symbol to tell disassembler in opcodes that
+ the code is MIPS16 or miscroMIPS. */
+ asym.flags = BSF_SYNTHETIC;
+ info->symtab_pos = 0;
+ info->symtab_size = 1;
+ info->symtab = ≈
+ info->symbols = ≈
+
+ if (mips_pc_is_mips16 (gdbarch, memaddr))
+ asym.udata.i = ELF_ST_SET_MIPS16 (asym.udata.i);
+ else
+ asym.udata.i = ELF_ST_SET_MICROMIPS (asym.udata.i);
+
+ /* Round down the instruction address to the appropriate
+ boundary. */
+ memaddr &= ~1;
+ }
+ else
+ memaddr &= ~3;
/* Set the disassembler options. */
if (!info->disassembler_options)
diff --git a/opcodes/mips-dis.c b/opcodes/mips-dis.c
index 4519500..d413841 100644
--- a/opcodes/mips-dis.c
+++ b/opcodes/mips-dis.c
@@ -2452,7 +2452,7 @@ is_compressed_mode_p (struct disassemble_info *info, bfd_boolean micromips_p)
int i;
int l;
- for (i = info->symtab_pos, l = i + info->num_symbols; i < l; i++)
+ for (i = info->symtab_pos, l = info->symtab_size; i < l; i++)
if (((info->symtab[i])->flags & BSF_SYNTHETIC) != 0
&& ((!micromips_p
&& ELF_ST_IS_MIPS16 ((*info->symbols)->udata.i))
next prev parent reply other threads:[~2017-07-07 16:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-16 10:49 [PATCH 0/6] Unify the disassembler selection in gdb and objdump Yao Qi
2017-05-16 10:48 ` [PATCH 5/6] Use disassble.c:disassembler select rs6000 disassembler Yao Qi
2017-05-16 10:48 ` [PATCH 4/6] Use disassble.c:disassembler select rl78 disassembler Yao Qi
2017-05-16 10:48 ` [PATCH 2/6] Delegate opcodes to select disassembler in GDB Yao Qi
2017-06-30 0:19 ` Maciej W. Rozycki
2017-06-30 7:38 ` Yao Qi
2017-07-05 23:53 ` Maciej W. Rozycki
2017-07-07 16:41 ` Yao Qi [this message]
2017-08-01 16:31 ` Maciej W. Rozycki
2017-05-16 10:49 ` [RFC 6/6] Move print_insn_XXX to an opcodes internal header Yao Qi
2017-05-16 10:49 ` [PATCH 1/6] Refactor disassembler selection Yao Qi
2017-05-16 10:49 ` [PATCH 3/6] Use disassble.c:disassembler select h8300 disassembler Yao Qi
2017-05-17 3:00 ` [PATCH 0/6] Unify the disassembler selection in gdb and objdump Alan Modra
2017-05-24 16:26 ` Yao Qi
2017-05-23 9:19 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=867ezk5hea.fsf@gmail.com \
--to=qiyaoltc@gmail.com \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=macro@imgtec.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox