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: Now I know why we used to swap builtin_type_void.


Daniel Jacobowitz <drow@false.org> writes:
> (top-gdb) p *builtin_type_void_data_ptr
> $24 = {pointer_type = 0x0, reference_type = 0x0, chain = 0x7b50d0,
>   instance_flags = 0, length = 8, main_type = 0x7b5100}
> (top-gdb) p current_gdbarch.ptr_bit
> $25 = 32
>
> Because we didn't swap out "void", we followed the cached pointer link
> in builtin_type_void when we tried to create a pointer to void.  My
> initial default gdbarch was 64-bit, because I built a 64-bit GDB
> binary.  So the cached pointer type is 64-bit.
>
> This is a mess.  I think we may need to revert the builtin_type_void
> patch unless you have a better idea.

I see --- because types point to their pointer types, if we need to
swap pointer types, we must also swap target types.

Why doesn't the same logic apply to the other types created in
_initialize_gdbtypes?  I believe they're never referred to by debug
information, and the user has no way to refer to them from the command
line, so that keeps us out of trouble in those cases.  But if some
architecture-specific code ever calls lookup_pointer_type on them,
won't we have the same problem you've discovered above with void?

I'll revert the patch.  It was just a cleanup; I don't actually need
it for anything.


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