This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] bfd/: bfd_elf_bfd_from_remote_memory 32bit &= 0xffffffff


>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Tom> It seems like you could just call the struct CORE_ADDR.

Jan> I thought it would be good to have different type for _address_ vs. for
Jan> _displacement_.  With this difference some math operations are no longer
Jan> valid and I have discovered for example:

Ok, I see.  But in that case wouldn't you still need (or want) to make
CORE_ADDR non-scalar, to avoid hidden errors?

Jan> displacement used as address: invalid but used in
Jan> read_type_unit_scope; it should get some cleanup (not investigated
Jan> more).

Yeah.  There's a comment:

  /* start_symtab needs a low pc, but we don't really have one.
     Do what read_file_scope would do in the absence of such info.  */
  lowpc = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile));

Tom> Maybe I am being fuzzy today, but I don't follow the logic of this
Tom> statement.  Is this just because we don't expect "too much" overflow?
Tom> Is it impossible for overflow to accumulate in a CORE_ADDR?

Jan> In general "displacement + displacement" operation is invalid and thus it
Jan> cannot overflow.

Thanks.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]