From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: patch to gdb on Tru64 5.1 Date: Tue, 08 May 2001 23:22:00 -0000 Message-id: <20010509082227.E23184@act-europe.fr> X-SW-Source: 2001-05/msg00119.html Hi, I am an employee of Ada Core Technologies, Inc, and I've done some work on gdb to make it work on Tru64 5.1 (it currently does not compile on this plateform). ACT is happy to contribute the changes that we made in the hope that it will be useful to others. Here is the patch agains the latest CVS sources that will allow gdb to compile and work on Tru64 5.1 using the native cc compiler. I don't know if it will successfully build with gcc. On top of the patch, there is this new file 'alpha-osf5.mh' in 'gdb/config/alpha' that will need to be created. I am attaching it as well. The ChangeLog: alpha-nat.c: ------------ fetch_osf_core_registers: adapt the table used to map the regnum to the core register section index to work on Tru64 5.1 as well. configure.host: --------------- set gdb_host to alpha-osf5 for Tru64 5+ (instead of alpha-osf3). osfsolib.c: ----------- in_solib_dynsym_resolve_code: provide a dummy implementation for this function. It is not used on Tru64, but is needed anyway to avoid undefined symbols (it is declared in solib.h, which is not target dependent). The best approach is probably to conditionalize the definition of this procedure in solib.h so that it is not defined when building on Tru64 5+, but I am not sure how to do that yet. alpha-osf5.mh: -------------- new file. This is a modified version of alpha-osf3.mh where -DUSE_LDR_ROUTINES is added to the compilation flags. This forces gdb to use the xproc library to load the symbols, instead of relying on an empirical algorithm (which does not work on Tru64 5.1 anymore). Added the associated linking flags to NAT_CLIBS. Cheers, -- Joel >From kettenis@wins.uva.nl Wed May 09 03:00:00 2001 From: Mark Kettenis To: gdb-patches@sources.redhat.com Subject: [PATCH]: More macro-into-function conversion for x86 Date: Wed, 09 May 2001 03:00:00 -0000 Message-id: <200105090959.f499xkE02434@delius.kettenis.local> X-SW-Source: 2001-05/msg00120.html Content-length: 3812 Checked in. Mark Index: ChangeLog from Mark Kettenis * i386-tdep.c (i386_register_virtual_type): New function. (i386_register_convertible): New function. * config/i386/tm-i386.h (REGISTER_VIRTUAL_TYPE): Redefine in terms of i386_register_virtual_type. (REGISTER_CONVERTIBLE): Redefine in terms of i386_register_convertible. (i386_register_virtual_type, i386_register_convertible): New prototypes. Index: i386-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/i386-tdep.c,v retrieving revision 1.29 diff -u -p -r1.29 i386-tdep.c --- i386-tdep.c 2001/04/19 11:39:47 1.29 +++ i386-tdep.c 2001/05/09 09:56:37 @@ -905,6 +905,37 @@ i386_extract_struct_value_address (char } +/* Return the GDB type object for the "standard" data type of data in + register REGNUM. Perhaps %esi and %edi should go here, but + potentially they could be used for things other than address. */ + +struct type * +i386_register_virtual_type (int regnum) +{ + if (regnum == PC_REGNUM || regnum == FP_REGNUM || regnum == SP_REGNUM) + return lookup_pointer_type (builtin_type_void); + + if (IS_FP_REGNUM (regnum)) + return builtin_type_long_double; + + if (IS_SSE_REGNUM (regnum)) + return builtin_type_v4sf; + + return builtin_type_int; +} + +/* Return true iff register REGNUM's virtual format is different from + its raw format. Note that this definition assumes that the host + supports IEEE 32-bit floats, since it doesn't say that SSE + registers need conversion. Even if we can't find a counterexample, + this is still sloppy. */ + +int +i386_register_convertible (int regnum) +{ + return IS_FP_REGNUM (regnum); +} + /* Convert data from raw format for register REGNUM in buffer FROM to virtual format with type TYPE in buffer TO. In principle both formats are identical except that the virtual format has two extra Index: config/i386/tm-i386.h =================================================================== RCS file: /cvs/src/src/gdb/config/i386/tm-i386.h,v retrieving revision 1.17 diff -u -p -r1.17 tm-i386.h --- config/i386/tm-i386.h 2001/04/19 11:39:48 1.17 +++ config/i386/tm-i386.h 2001/05/09 09:56:37 @@ -238,23 +238,17 @@ extern int i386_register_virtual_size[]; /* Largest value REGISTER_VIRTUAL_SIZE can have. */ #define MAX_REGISTER_VIRTUAL_SIZE 16 -/* Return the GDB type object for the "standard" data type of data in - register N. Perhaps si and di should go here, but potentially they - could be used for things other than address. */ +/* Return the GDB type object for the "standard" data type of data in + register REGNUM. */ -#define REGISTER_VIRTUAL_TYPE(N) \ - (((N) == PC_REGNUM || (N) == FP_REGNUM || (N) == SP_REGNUM) \ - ? lookup_pointer_type (builtin_type_void) \ - : IS_FP_REGNUM(N) ? builtin_type_long_double \ - : IS_SSE_REGNUM(N) ? builtin_type_v4sf \ - : builtin_type_int) +#define REGISTER_VIRTUAL_TYPE(regnum) i386_register_virtual_type (regnum) +extern struct type *i386_register_virtual_type (int regnum); -/* REGISTER_CONVERTIBLE(N) is true iff register N's virtual format is - different from its raw format. Note that this definition assumes - that the host supports IEEE 32-bit floats, since it doesn't say - that SSE registers need conversion. Even if we can't find a - counterexample, this is still sloppy. */ -#define REGISTER_CONVERTIBLE(n) (IS_FP_REGNUM (n)) +/* Return true iff register REGNUM's virtual format is different from + its raw format. */ + +#define REGISTER_CONVERTIBLE(regnum) i386_register_convertible (regnum) +extern int i386_register_convertible (int regnum); /* Convert data from raw format for register REGNUM in buffer FROM to virtual format with type TYPE in buffer TO. */