From: "J. Johnston" <jjohnstn@redhat.com>
To: Marcel Moolenaar <marcel@xcllnt.net>
Cc: kettenis@gnu.org, gdb@sources.redhat.com
Subject: Re: Problem with deprecated_select_gdbarch_hack
Date: Wed, 05 Nov 2003 20:39:00 -0000 [thread overview]
Message-ID: <3FA95FEA.4090201@redhat.com> (raw)
In-Reply-To: <20031104003735.GA84210@dhcp01.pn.xcllnt.net>
Marcel Moolenaar wrote:
> On Mon, Nov 03, 2003 at 07:01:04PM -0500, J. Johnston wrote:
>
>>Mark,
>>
>> The current mainline gdb fails for ia64 linux due to an assertion in
>>deprecated_select_gdbarch_hack(). I noticed you added this code recently.
>>I have attached a scripted session with set debug arch 1. Can you verify
>>if the debug messages indicate any unanticipated path through your code? I
>>am just trying to debug a simple "hello world" program.
>
>
> I noticed it too. The gdb_assert() in deprecated_select_gdbarch_hack()
> is faulty because gdbarch_update_p() does not necessarily change the
> current gdbarch to the one passed to deprecated_select_gdbarch_hack().
> It can leave the gdbarch unchanged if it's semantically equivalent to
> the one asked to change to. Removal of the faulty gdb_assert() should
> do the trick.
>
I have recently checked in a change to the ia64-tdep.c code to modernize it to
grab the osabi from the gdbarch_info parameter and to call
gdbarch_list_lookup_by_info() to look for existing gdbarch candidates. This
fixes the problem without having to remove the assertion. Perhaps leaving the
assertion will point out any existing platforms that use the older code ia64 was
formerly using.
-- Jeff J.
> ...
>
>>gdbarch_update: info.bfd_arch_info ia64-elf64
>>gdbarch_update: info.byte_order 1 (little)
>>gdbarch_update: info.osabi 5 (GNU/Linux)
>>gdbarch_update: info.abfd 0x60000000000f16b0
>>gdbarch_update: info.tdep_info 0x0
>>gdbarch_update: New architecture 0x6000000000102590 (ia64-elf64) selected
>
> ...
>
>>gdbarch_update: info.bfd_arch_info ia64-elf64
>>gdbarch_update: info.byte_order 1 (little)
>>gdbarch_update: info.osabi 5 (GNU/Linux)
>>gdbarch_update: info.abfd 0x0
>>gdbarch_update: info.tdep_info 0x0
>>gdbarch_update: Previous architecture 0x60000000000b2620 (ia64-elf64) selected
>>gdbarch_update: info.bfd_arch_info ia64-elf64
>>gdbarch_update: info.byte_order 1 (little)
>>gdbarch_update: info.osabi 5 (GNU/Linux)
>>gdbarch_update: info.abfd 0x0
>>gdbarch_update: info.tdep_info 0x0
>>gdbarch_update: Architecture 0x60000000000b2620 (ia64-elf64) unchanged
>
> ...
>
prev parent reply other threads:[~2003-11-05 20:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-04 0:01 J. Johnston
2003-11-04 0:38 ` Marcel Moolenaar
2003-11-05 20:39 ` J. Johnston [this message]
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=3FA95FEA.4090201@redhat.com \
--to=jjohnstn@redhat.com \
--cc=gdb@sources.redhat.com \
--cc=kettenis@gnu.org \
--cc=marcel@xcllnt.net \
/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