From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Stephane Carrez <Stephane.Carrez@worldnet.fr>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Date: Mon, 27 Mar 2000 12:23:00 -0000 [thread overview]
Message-ID: <npd7og40xc.fsf@zwingli.cygnus.com> (raw)
In-Reply-To: <38D7E6BC.79543EBA@worldnet.fr>
Hmm.
The only actual use of address_significant_size is in
dwarf2read.c:read_address. That function extracts an address from the
Dwarf 2 data, using the address size given in the Dwarf 2 compilation
unit header. Then, it masks off any bits beyond the size given by
address_significant_size.
According to the comment for address_significant_size, this is
necessary for handling Dwarf 2 data with 64-bit addresses carried in
ELF32 files --- code for a 64-bit processor, linked to run in a 32-bit
address space.
But I don't understand why we're masking those bits off at all.
Suppose we do have 64-bit addresses in the debug info --- shouldn't
all 64 bits be correct? Why should GDB mask them off and make them
zero --- why doesn't GCC or GAS just emit the address correctly in the
first place?
In the absence of further explanation, it looks to me like this code
is an incorrect attempt to compensate for a bug elsewhere in the
toolchain, and address_significant_size should be removed altogether.
Or maybe I'm misunderstanding things. Andrew, as the committer of
this change, can you comment?
Mon Dec 15 11:38:52 1997 Andrew Cagney <cagney@b1.cygnus.com>
* dwarf2read.c: From change proposed by Gavin Koch.
(address_significant_size): New static variable.
(dwarf2_build_psymtabs_hard): Check consistency between
`address_size' and `address_significant_size'.
(read_address): MASK out all but the significant bits, as
determined by `address_significant_size', of any addresses.
(elf-bfd.h): Include.
(dwarf2_build_psymtabs_hard): Set `address_significant_size'
according to the arch_size of the elf object file.
next prev parent reply other threads:[~2000-03-27 12:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <38D4DCB0.88313CB2@worldnet.fr>
[not found] ` <38D5B6E0.50FF6A5E@cygnus.com>
[not found] ` <38D68C56.856CB00C@worldnet.fr>
2000-04-01 0:00 ` Andrew Cagney
[not found] ` <38D7E6BC.79543EBA@worldnet.fr>
2000-03-27 12:23 ` Jim Blandy [this message]
[not found] ` <38E06721.6D3A08CD@cygnus.com>
[not found] ` <npsnx91szl.fsf@zwingli.cygnus.com>
2000-04-01 0:00 ` Andrew Cagney
[not found] ` <npem8w42bg.fsf@zwingli.cygnus.com>
2000-04-01 0:00 ` Fernando Nasser
2000-04-01 0:00 Stephane Carrez
[not found] ` <38BB5463.D6E5B75C@cygnus.com>
[not found] ` <38C0D9D9.70987863@worldnet.fr>
[not found] ` <38C225F3.9E236A55@cygnus.com>
2000-03-28 8:24 ` Jim Blandy
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=npd7og40xc.fsf@zwingli.cygnus.com \
--to=jimb@zwingli.cygnus.com \
--cc=Stephane.Carrez@worldnet.fr \
--cc=ac131313@cygnus.com \
--cc=gdb-patches@sourceware.cygnus.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