From: Joel Brobecker <brobecker@adacore.com>
To: "Maciej W. Rozycki" <macro@codesourcery.com>
Cc: gdb-patches@sourceware.org, Rich Fuhler <rich@mips.com>,
Richard Sandiford <rdsandiford@googlemail.com>,
binutils@sourceware.org, gcc@gcc.gnu.org
Subject: Re: [RFD+PATCH] ISA bit treatment on the MIPS platform
Date: Mon, 11 Jun 2012 18:21:00 -0000 [thread overview]
Message-ID: <20120611182043.GA7597@adacore.com> (raw)
In-Reply-To: <alpine.DEB.1.10.1204202134510.19835@tp.orcam.me.uk>
> I propose therefore to accept the existing inconsistencies and deal
> with them entirely within GDB. I have figured out that the ISA bit
> lost in various places can still be recovered as long as we have
> symbol information -- that'll have the st_other attribute correctly
> set to one of standard MIPS/MIPS16/microMIPS.
That seems reasonable to me.
> 2012-05-14 Maciej W. Rozycki <macro@codesourcery.com>
> Maciej W. Rozycki <macro@mips.com>
> Pedro Alves <pedro@codesourcery.com>
>
> * gdbarch.sh (make_symbol_special): New architecture method.
> (adjust_dwarf2_addr, adjust_dwarf2_line): Likewise.
> (objfile, symbol): New declarations.
> * arch-utils.h (default_make_symbol_special): New prototype.
> (default_adjust_dwarf2_addr): Likewise.
> (default_adjust_dwarf2_line): Likewise.
> * arch-utils.c (default_make_symbol_special): New function.
> * dwarf2-frame.c (decode_frame_entry_1): Call
> gdbarch_adjust_dwarf2_addr.
> * dwarf2loc.c (dwarf2_find_location_expression): Likewise.
> * dwarf2read.c (read_func_scope): Call
> gdbarch_make_symbol_special.
> (dwarf2_ranges_read): Call gdbarch_adjust_dwarf2_addr.
> (read_attribute_value): Likewise.
> (dwarf_decode_lines_1): Call gdbarch_adjust_dwarf2_line.
> * mips-tdep.c (mips_elf_make_msymbol_special): Set the ISA bit
> in the symbol's address appropriately.
> (mips_make_symbol_special): New function.
> (mips_pc_is_mips): Set the ISA bit before symbol lookup.
> (mips_pc_is_mips16): Likewise.
> (mips_pc_is_micromips): Likewise.
> (mips_pc_isa): Likewise.
> (mips_adjust_dwarf2_addr): New function.
> (mips_adjust_dwarf2_line): Likewise.
> (mips_read_pc, mips_unwind_pc): Keep the ISA bit.
> (mips_addr_bits_remove): Likewise.
> (mips_skip_trampoline_code): Likewise.
> (mips_write_pc): Don't set the ISA bit.
> (mips_eabi_push_dummy_call): Likewise.
> (mips_o64_push_dummy_call): Likewise.
> (mips_gdbarch_init): Install mips_make_symbol_special,
> mips_adjust_dwarf2_addr and mips_adjust_dwarf2_line gdbarch
> handlers.
> * solib.c (gdb_bfd_lookup_symbol_from_symtab): Get
> target-specific symbol address adjustments.
> * gdbarch.h: Regenerate.
> * gdbarch.c: Regenerate.
From the ChangeLog entry, it seems like Pedro was involved in the making
of that patch, so perhaps he could be a good reviewer? There are also
changes in dwarf2*, so perhaps people such as Doug and Tom could also
be involved....
Just some minor comments below:
> gdb-mips16-isa-bit.diff
> Index: gdb-fsf-trunk-quilt/gdb/mips-tdep.c
> ===================================================================
> --- gdb-fsf-trunk-quilt.orig/gdb/mips-tdep.c 2012-05-14 16:00:33.000000000 +0100
> +++ gdb-fsf-trunk-quilt/gdb/mips-tdep.c 2012-05-14 16:02:02.235560558 +0100
> @@ -358,9 +358,15 @@ mips_elf_make_msymbol_special (asymbol *
> return;
>
> if (ELF_ST_IS_MICROMIPS (elfsym->internal_elf_sym.st_other))
> - MSYMBOL_TARGET_FLAG_2 (msym) = 1;
> + {
> + MSYMBOL_TARGET_FLAG_2 (msym) = 1;
> + SYMBOL_VALUE_ADDRESS (msym) |= 1;
> + }
> else if (ELF_ST_IS_MIPS16 (elfsym->internal_elf_sym.st_other))
> - MSYMBOL_TARGET_FLAG_1 (msym) = 1;
> + {
> + MSYMBOL_TARGET_FLAG_1 (msym) = 1;
> + SYMBOL_VALUE_ADDRESS (msym) |= 1;
> + }
This remark is not to be considered as part of this patch's review,
since this is already an established practice, but I think we could do
better than using magic numbers for those flags. I understand they have
to be that way in the common code, but perhaps mips-tdep could define
aliases? Something like MSYMBOL_MIPS_TARGET_FLAG_BLAH?
> Index: gdb-fsf-trunk-quilt/gdb/arch-utils.c
[...]
> +void
> +default_make_symbol_special (struct symbol *sym, struct objfile *objfile)
Can you put a comment at the start of all these new functions to say
that the documentation is in the header file? For instance, I think
we typically say:
/* See arch-utils.h. */
This is to help someone reviewing the code to know that there is
in fact documentation.
> +/* Do nothing version of make_symbol_special. */
> +
> +void default_make_symbol_special (struct symbol *sym, struct objfile *objfile);
> +
> +/* Do nothing version of adjust_dwarf2_addr. */
> +
> +CORE_ADDR default_adjust_dwarf2_addr (CORE_ADDR pc);
> +
> +/* Do nothing version of adjust_dwarf2_line. */
> +
> +CORE_ADDR default_adjust_dwarf2_line (CORE_ADDR addr, int rel);
I would definitely mention gdbarch in the function comment.
Prior art uses:
/* Default implementation of gdbarch_displaced_hw_singlestep. */
Should we remain consistent with that? It can be a mix of both,
saying what method it implements, and then what it actually does, Eg:
/* Default version of gdbarch_make_symbol_special (does nothing). */
> Index: gdb-fsf-trunk-quilt/gdb/solib.c
> ===================================================================
> --- gdb-fsf-trunk-quilt.orig/gdb/solib.c 2012-05-14 15:56:45.000000000 +0100
> +++ gdb-fsf-trunk-quilt/gdb/solib.c 2012-05-14 16:01:34.645558637 +0100
> @@ -1384,8 +1384,27 @@ gdb_bfd_lookup_symbol_from_symtab (bfd *
>
> if (match_sym (sym, data))
> {
> + symaddr = sym->value;
> +
> + /* macro/2012-04-20: Some ELF targets fiddle with addresses
> + of symbols they consider special. They use minimal symbols
> + to do that and this is needed for correct breakpoint
> + placement, but we do not have full data here to build a
> + complete minimal symbol, so just set the address and let the
> + targets cope with that. */
> + if (bfd_get_flavour (abfd) == bfd_target_elf_flavour)
> + {
> + struct minimal_symbol msym;
> +
> + memset (&msym, 0, sizeof (msym));
> + SYMBOL_VALUE_ADDRESS (&msym) = symaddr;
> + gdbarch_elf_make_msymbol_special (target_gdbarch,
> + sym, &msym);
> + symaddr = SYMBOL_VALUE_ADDRESS (&msym);
> + }
Is there a way we could avoid that block if
gdbarch_elf_make_msymbol_special points to the default implementation?
It just seems sad to be doing all this work of creating a temporary symbol
for every solib symbol on non-mips targets...
One possible way would have been to provide no default value for
gdbarch_elf_make_msymbol_special, but then it makes the calling
of that method a little trickier. That could be worked around by
changing the default value of gdbarch_elf_make_msymbol_special to NULL,
and then having an extra wrapper function that call the gdbarch
method if not NULL or else does nothing.
--
Joel
next prev parent reply other threads:[~2012-06-11 18:21 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-14 15:37 Maciej W. Rozycki
2012-05-18 22:01 ` Maciej W. Rozycki
2012-06-11 18:21 ` Joel Brobecker [this message]
2012-06-12 14:05 ` Pedro Alves
2014-10-06 0:42 ` [PATCH v2 1/2] " Maciej W. Rozycki
2014-10-06 0:42 ` [PATCH v2 2/2] Correct invalid assumptions made by (mostly) DWARF-2 tests Maciej W. Rozycki
2014-11-16 11:09 ` Joel Brobecker
2014-11-16 18:32 ` Doug Evans
2014-11-16 19:49 ` Doug Evans
2014-11-16 20:05 ` Maciej W. Rozycki
2014-11-16 21:52 ` Doug Evans
2014-12-04 0:24 ` Maciej W. Rozycki
2014-11-16 22:28 ` Doug Evans
2014-10-06 14:10 ` [PATCH v2 1/2] ISA bit treatment on the MIPS platform Joel Brobecker
2014-10-14 20:45 ` Maciej W. Rozycki
2014-10-20 17:10 ` [PING][PATCH " Maciej W. Rozycki
2014-11-03 16:13 ` [PING^2][PATCH " Maciej W. Rozycki
2014-11-16 19:23 ` [PATCH " Doug Evans
2014-10-06 15:43 ` Maciej W. Rozycki
2014-11-16 10:37 ` Joel Brobecker
2014-11-16 19:27 ` Doug Evans
2014-12-04 23:14 ` Maciej W. Rozycki
2014-12-12 14:00 ` Maciej W. Rozycki
2014-12-12 17:22 ` Doug Evans
2014-11-17 1:17 ` Doug Evans
2014-12-04 15:31 ` Maciej W. Rozycki
2014-12-12 16:38 ` [committed] MIPS: Define aliases for MSYMBOL_TARGET_FLAG macros Maciej W. Rozycki
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=20120611182043.GA7597@adacore.com \
--to=brobecker@adacore.com \
--cc=binutils@sourceware.org \
--cc=gcc@gcc.gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=macro@codesourcery.com \
--cc=rdsandiford@googlemail.com \
--cc=rich@mips.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).