Bug 22718 - Support ambiguous types
Summary: Support ambiguous types
Status: RESOLVED DUPLICATE of bug 11035
Alias: None
Product: gdb
Classification: Unclassified
Component: cli (show other bugs)
Version: HEAD
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-16 20:11 UTC by jhb
Modified: 2023-12-27 13:12 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jhb 2018-01-16 20:11:17 UTC
GDB supports disambiguating program variables by using a filename or function to identify the scope of an ambiguous variable (e.g. "foo.c"::bar).  However, there is not (as far as I can find) a similar mechanism for ambiguous types.  That is, suppose a C program defines two different 'struct foo' types in separate source files.  I cannot construct a cast for a void * pointer to a specific 'struct foo *'.

As a concrete example, the FreeBSD kernel contains two definitions of 'struct elf_file' in the files sys/kern/link_elf.c and sys/kern/link_elf_obj.c.  'info types elf_file' finds both types fine:

(gdb) info types elf_file
All types matching regular expression "elf_file":

File /mnt/jhb/work/git/freebsd/sys/kern/link_elf.c:
struct elf_file;
typedef struct elf_file * elf_file_t;

File /mnt/jhb/work/git/freebsd/sys/kern/link_elf_obj.c:
struct elf_file;
typedef struct elf_file * elf_file_t;

However, attempting to cast a pointer to one of these types alway uses the first type (and in this case I really want to use the second type):

(gdb) set $ef = (struct elf_file *)linker_files->tqh_first->link->tqe_next

Trying to use the filename as a scope gives a syntax error:

(gdb) set $ef = ("link_elf_obj.c"::struct elf_file *)linker_files->tqh_first->link->tqe_next
A syntax error in expression, near `::struct elf_file *)linker_files->tqh_first->link->tqe_next'.
Comment 1 Hannes Domani 2023-12-27 13:12:13 UTC
Dup.

*** This bug has been marked as a duplicate of bug 11035 ***