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: [rfc][21/37] Eliminate builtin_type_ macros: Platform-neutral builtin_type_void


> However, this problem can be fixed by simply making sure that noone
> ever calls lookup_pointer_type, lookup_reference_type, or lookup_function_type
> on the platform-neutral builtin_type_void type.

I am really concerned that, one day, we will miss someone re-introducing
a call to one of these functions with the builtin_type_void type
It would be really useful to do whatever we can to prevent this
from happening.

I don't want to add a field in our type structure to mark the types
that are architecture-specific, since that would have a noticeable
memory cost just for a few specific types. So about the following,
not ideal but probably good enough:

  - Add a new function architecture_neutral_builtin_type () that
    returns true/non-zero if the given type is one of the builtin
    types defined by gdbtypes (just doing a pointer check against
    every builtin_type_* that we have)

  - Add an assertion in lookup_pointer_type, lookup_reference_type,
    and lookup_function_type using the function above.

  - Add a comment a the beginning of the builtin_type section explaining
    that the following types are architecture neutral, and that computing
    pointer/reference/function types should not be performed on them.
    Explicitly remind the reader that when adding a new builtin type
    there, he should also update the check in
    architecture_neutral_builtin_type.

Another option is to generate the builtin types and the associated
architecture_neutral_builtin_type function a-la gdbarch. Probably
cleaner, as less error prone.

This doesn't have to be done as part of this patch, though, especially
since this is open to discussion. Perhaps shortly after this patch set
is checked in, we could make sure to follow up on that?

-- 
Joel


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