This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] bfd/: bfd_elf_bfd_from_remote_memory 32bit &= 0xffffffff
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 16 Feb 2010 16:24:01 -0700
- Subject: Re: [patch] bfd/: bfd_elf_bfd_from_remote_memory 32bit &= 0xffffffff
- References: <20100211115730.GA7358@host0.dyn.jankratochvil.net> <m3tytoynpk.fsf@hase.home> <20100211124302.GA8435__38068.0548646071$1265892205$gmane$org@host0.dyn.jankratochvil.net>
- Reply-to: tromey at redhat dot com
Jan> +typedef struct
Jan> + {
Jan> + CORE_ADDR a;
Jan> + }
Jan> +addr_offset_t;
I like this idea. It is slightly less convenient, but also lets us
control the operations more tightly.
Math on an addr_offset_t would seem to depend on the current target (or
address space). This is a little gross ... but still it seems like a
decent step.
It seems like you could just call the struct CORE_ADDR.
I am curious to hear what others think of this.
Jan> But as I see now fixing few GDB places to always sign-extend the
Jan> displacement CORE_ADDR will permit using the current standard 64bit
Jan> math operators even for 32bit inferiors.
Maybe I am being fuzzy today, but I don't follow the logic of this
statement. Is this just because we don't expect "too much" overflow?
Is it impossible for overflow to accumulate in a CORE_ADDR?
Tom