From: "H.J. Lu" <hjl.tools@gmail.com>
To: "H.J. Lu" <hjl.tools@gmail.com>,
Mark Kettenis <mark.kettenis@xs4all.nl>,
gdb-patches@sourceware.org
Subject: Re: PATCH: Enable x86 XML target descriptions
Date: Mon, 22 Feb 2010 15:39:00 -0000 [thread overview]
Message-ID: <6dc9ffc81002220739q5b6e082ev452d07b80a5df169@mail.gmail.com> (raw)
In-Reply-To: <20100222152955.GB30100@caradoc.them.org>
On Mon, Feb 22, 2010 at 7:29 AM, Daniel Jacobowitz <dan@codesourcery.com> wrote:
> On Mon, Feb 22, 2010 at 07:27:30AM -0800, H.J. Lu wrote:
>> It works fine. amd64_linux_read_description is called via
>
> Does it work fine for the right reason? gdbarch has not been set yet.
> How can the gdbarch know if the PID is a 32-bit or 64-bit process?
>
From
(gdb) att 20196
Attaching to process 20196
Reading symbols from /export/home/hjl/bugs/gdb/xml/p...done.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Detaching after fork from child process 20207.
Breakpoint 3, amd64_linux_read_description (ops=0xa94900)
at /export/gnu/import/git/gdb-avx/gdb/amd64-linux-nat.c:681
681 {
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-8.fc12.x86_64 ncurses-libs-5.7-3.20090207.fc12.x86_64
python-2.6.2-2.fc12.x86_64 python-libs-2.6.2-2.fc12.x86_64
zlib-1.2.3-23.fc12.x86_64
(top-gdb) p target_gdbarch
$1 = (struct gdbarch *) 0xbb3660
(top-gdb) p *target_gdbarch
$2 = {initialized_p = 1, obstack = 0xbb35f0, bfd_arch_info = 0x7bd0a0,
byte_order = 1, byte_order_for_code = 1, osabi = GDB_OSABI_LINUX,
target_desc = 0x0, tdep = 0xbb3500, dump_tdep = 0, nr_data = 18,
data = 0xbb3a30, swap = 0x0, bits_big_endian = 0, short_bit = 16,
int_bit = 32, long_bit = 32, long_long_bit = 64, float_bit = 32,
float_format = 0xa4e6e0, double_bit = 64, double_format = 0xa4e6f0,
long_double_bit = 96, long_double_format = 0xa4e710, ptr_bit = 32,
addr_bit = 32, char_signed = 1, read_pc = 0,
write_pc = 0x4758b0 <i386_linux_write_pc>,
virtual_frame_pointer = 0x5418a0 <legacy_virtual_frame_pointer>,
pseudo_register_read = 0x46c1d0 <i386_pseudo_register_read>,
pseudo_register_write = 0x46c110 <i386_pseudo_register_write>,
num_regs = 42, num_pseudo_regs = 8, sp_regnum = 4, pc_regnum = 8,
ps_regnum = 9, fp0_regnum = 16,
stab_reg_to_regnum = 0x46aef0 <i386_svr4_reg_to_regnum>,
ecoff_reg_to_regnum = 0x540a60 <no_op_reg_to_regnum>,
sdb_reg_to_regnum = 0x46ae40 <i386_dbx_reg_to_regnum>,
dwarf2_reg_to_regnum = 0x46aef0 <i386_svr4_reg_to_regnum>,
register_name = 0x5c46f0 <tdesc_register_name>,
register_type = 0x5c4df0 <tdesc_register_type>,
dummy_id = 0x46b810 <i386_dummy_id>, deprecated_fp_regnum = -1,
push_dummy_call = 0x46c6f0 <i386_push_dummy_call>, call_dummy_location = 4,
push_dummy_code = 0,
---Type <return> to continue, or q <return> to quit---q
print_registers_info = 0x51dcb0 <default_print_registers_Quit
(top-gdb) p *target_gdbarch->bfd_arch_info
$3 = {bits_per_word = 32, bits_per_address = 32, bits_per_byte = 8,
arch = bfd_arch_i386, mach = 1, arch_name = 0x7b3bb2 "i386",
printable_name = 0x7b3bb2 "i386", section_align_power = 3, the_default = 1,
compatible = 0x609fa0 <bfd_default_compatible>,
scan = 0x60a110 <bfd_default_scan>, next = 0x7bd100}
(top-gdb)
Gdb will load executable before calling amd64_linux_read_description
At this point, target_gdbarch is set and knows inferior is 32bit or not.
--
H.J.
next prev parent reply other threads:[~2010-02-22 15:39 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-10 20:03 H.J. Lu
2010-02-17 14:59 ` H.J. Lu
2010-02-17 15:23 ` Mark Kettenis
2010-02-17 15:42 ` H.J. Lu
2010-02-17 15:46 ` Daniel Jacobowitz
2010-02-17 16:19 ` Mark Kettenis
2010-02-18 5:44 ` H.J. Lu
2010-02-18 15:37 ` H.J. Lu
2010-02-18 23:01 ` H.J. Lu
2010-02-22 13:42 ` Mark Kettenis
2010-02-22 14:17 ` H.J. Lu
2010-02-22 15:01 ` Mark Kettenis
2010-02-22 15:27 ` H.J. Lu
2010-02-22 15:30 ` Daniel Jacobowitz
2010-02-22 15:39 ` H.J. Lu [this message]
2010-02-28 20:30 ` Mark Kettenis
2010-02-28 20:58 ` H.J. Lu
2010-02-28 22:23 ` Daniel Jacobowitz
2010-02-22 14:41 ` Daniel Jacobowitz
2010-02-22 15:34 ` H.J. Lu
2010-02-22 15:52 ` Daniel Jacobowitz
2010-02-22 15:58 ` H.J. Lu
2010-02-22 16:10 ` Daniel Jacobowitz
2010-02-22 16:58 ` Mark Kettenis
2010-02-22 17:03 ` Daniel Jacobowitz
2010-02-22 19:52 ` Mark Kettenis
2010-02-22 21:06 ` H.J. Lu
2010-02-22 21:31 ` Mark Kettenis
2010-02-22 21:41 ` H.J. Lu
2010-02-22 22:05 ` H. Peter Anvin
2010-02-22 22:07 ` H.J. Lu
2010-02-22 22:15 ` H. Peter Anvin
2010-02-22 22:21 ` H.J. Lu
2010-02-28 20:12 ` Mark Kettenis
2010-02-22 21:04 ` H.J. Lu
2010-02-28 21:16 ` H.J. Lu
2010-03-01 14:49 ` Mark Kettenis
2010-03-01 17:07 ` Daniel Jacobowitz
2010-03-01 17:09 ` H.J. Lu
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=6dc9ffc81002220739q5b6e082ev452d07b80a5df169@mail.gmail.com \
--to=hjl.tools@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
/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