From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: Geoff Keating Cc: guo@cup.hp.com, fnasser@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: recent dejagnu changes Date: Tue, 08 Aug 2000 12:52:00 -0000 Message-id: <39906503.205B3220@apple.com> References: <200008081827.LAA06137@localhost.cygnus.com> X-SW-Source: 2000-08/msg00156.html Geoff Keating wrote: > > dejagnu is shared between GDB, GCC, and binutils, just as BFD is > shared between binutils and GDB. For such shared code, it is > extremely impolite to make a change without testing it on all the > users. However, in the absence of a dejagnu maintainer, I don't think it's unreasonable of Jimmy to ask for help in validating the testing framework on packages with which he is unfamiliar. For instance, if he doesn't know what the expected behavior is supposed to be with the GCC testsuite, how is having him run the testsuite one time going to be helpful? Also, what would you suggest if, as is frequently the case, he tries to build GCC from CVS and it doesn't even build on his machine, let alone get to the point of being able to test it? Since we all have a common interest in making dejagnu work well, and no benevolent dejagnu dictator to force us to get along :-), let's try to help each other here. Stan >From tromey@cygnus.com Tue Aug 08 13:14:00 2000 From: Tom Tromey To: gdb-patches@sourceware.cygnus.com Subject: Patch: Java -vs- null strings Date: Tue, 08 Aug 2000 13:14:00 -0000 Message-id: <877l9ro68c.fsf@creche.i-did-not-set--mail-host-address--so-shoot-me> X-SW-Source: 2000-08/msg00157.html Content-length: 1138 If you are debugging a Java program and try to print a String variable whose value is null you will see this: (gdb) p name $3 = Cannot access memory at address 0x8 This is lame. The appended patch fixes gdb to do this: (gdb) p p $1 = null Is this ok? 2000-08-08 Tom Tromey * jv-valprint.c (java_value_print): Only print non-null Strings. Tom Index: jv-valprint.c =================================================================== RCS file: /cvs/src/src/gdb/jv-valprint.c,v retrieving revision 1.3 diff -u -r1.3 jv-valprint.c --- jv-valprint.c 2000/07/30 01:48:26 1.3 +++ jv-valprint.c 2000/08/08 20:11:49 @@ -197,9 +197,10 @@ if (TYPE_CODE (type) == TYPE_CODE_PTR && TYPE_TARGET_TYPE (type) && TYPE_NAME (TYPE_TARGET_TYPE (type)) - && strcmp (TYPE_NAME (TYPE_TARGET_TYPE (type)), "java.lang.String") == 0 + && strcmp (TYPE_NAME (TYPE_TARGET_TYPE (type)), "java.lang.String") == 0 && (format == 0 || format == 's') - && address != 0) + && address != 0 + && value_as_pointer (val) != 0) { value_ptr data_val; CORE_ADDR data; >From nickc@redhat.com Tue Aug 08 14:22:00 2000 From: Nick Clifton To: gdb-patches@sources.redhat.com Subject: RFA: Recording MIPS ABI selection in binaries Date: Tue, 08 Aug 2000 14:22:00 -0000 Message-id: <200008082122.OAA19523@elmo.cygnus.com> X-SW-Source: 2000-08/msg00158.html Content-length: 7919 Hi Guys, There is a problem with the MIPS port. There is no way for GDB to tell if a binary has been produced with the -mgp32 option. This means that attempts to debug such binaries will usually fail horribly, since GDB has the wrong idea about the size of various types and so on. This kind of problem used to be solved by setting a flag bit in the file header, but in this case the appropriate bit has already been taken by the 64 bit binaries, so I have come up with a different solution. My solution is to have GCC create an empty, uniquely named section indicating the ABI in use. GDB then detects the presence of this section and selects the ABI appropriately. If it does not find the section then it goes back to its old method of examining the flags in the ELF header. I have tested the patch and it reduces the number of GDB testsuite failures from 1280 to 450 when the -mgp32 switch is used. This patch has the advantage of being simple - no changes are needed to the assembler or linker and only mips specific code in GCC and GDB are affected - and space efficient - the sections are empty, only occupy a small amount of space in the binary, do not get loaded into memory, and get merged together when the object files are linked. But perhaps there is a better solution in creating a .note section instead, I am not sure. The problem as I see it with creating a .note section, is that the notes in the section will not be merged together when the object files are linked together. Thus the section could start taking up a non-trivial amount of space in the resultant binary. It is also more complex for GDB if it has to read in the .note section's contents and then parse them. So, I am presenting my patch below for discussion and possible approval. What do people think ? Cheers Nick gcc ChangeLog: 2000-08-08 Nick Clifton * config/mips/mips.c (mips_asm_file_start): Create a .mdebug.XXX section where XXX is the ABI in use. gdb ChangeLog: 2000-08-08 Nick Clifton * mips-tdep.c (mips_gdbarch_init): Scan for a .mdebug.XXX section and initialise the ABI from that, if found. Index: gcc/config/mips/mips.c =================================================================== RCS file: /cvs/gcc/egcs/gcc/config/mips/mips.c,v retrieving revision 1.96 diff -p -r1.96 mips.c *** mips.c 2000/08/08 01:17:06 1.96 - --- mips.c 2000/08/08 20:55:35 *************** void *** 5907,5912 **** - --- 5907,5914 ---- mips_asm_file_start (stream) FILE *stream; { + const char * abi_string = NULL; + ASM_OUTPUT_SOURCE_FILENAME (stream, main_input_filename); /* Versions of the MIPS assembler before 2.20 generate errors if a branch *************** mips_asm_file_start (stream) *** 5916,5921 **** - --- 5918,5943 ---- if (TARGET_MIPS_AS && optimize && flag_delayed_branch) fprintf (stream, "\t.set\tnobopt\n"); + + /* Generate a special section to describe the ABI switches used to produce + the resultant binary. This used to be done by the assembler setting bits + in the ELF header's flags field, but we have run out of bits. GDB needs + this information in order to be able to correctly debug these binaries. + See the function mips_gdbarch_init() in gdb/mips-tdep.c. */ + switch (mips_abi) + { + case ABI_32: abi_string = "abi32"; break; + case ABI_N32: abi_string = "abiN32"; break; + case ABI_64: abi_string = "abi64"; break; + case ABI_O64: abi_string = "abiO64"; break; + case ABI_EABI: abi_string = TARGET_64BIT ? "eabi64" : "eabi32"; break; + default: + abort (); + } + fprintf (stream, "\t.section .mdebug.%s\n", abi_string); + + /* Restore the default section. */ + fprintf (stream, "\t.section .text\n"); /* Generate the pseudo ops that System V.4 wants. */ #ifndef ABICALLS_ASM_OP Index: gdb/mips-tdep.c =================================================================== RCS file: /cvs/src//src/gdb/mips-tdep.c,v retrieving revision 1.29 diff -p -w -r1.29 mips-tdep.c *** mips-tdep.c 2000/07/30 01:48:26 1.29 - --- mips-tdep.c 2000/08/08 20:57:40 *************** mips_gdbarch_init (struct gdbarch_info i *** 3813,3828 **** {0}; struct gdbarch *gdbarch; struct gdbarch_tdep *tdep; ! int elf_flags; ! enum mips_abi mips_abi; ! /* Extract the elf_flags if available */ if (info.abfd != NULL && bfd_get_flavour (info.abfd) == bfd_target_elf_flavour) elf_flags = elf_elfheader (info.abfd)->e_flags; else ! elf_flags = 0; /* Check ELF_FLAGS to see if it specifies the ABI being used. */ switch ((elf_flags & EF_MIPS_ABI)) { - --- 3813,3873 ---- {0}; struct gdbarch *gdbarch; struct gdbarch_tdep *tdep; ! int elf_flags = 0; ! enum mips_abi mips_abi = MIPS_ABI_UNKNOWN; ! /* Extract the elf_flags if available. */ if (info.abfd != NULL && bfd_get_flavour (info.abfd) == bfd_target_elf_flavour) + { + asection * note; + const char * abi_sec = ".mdebug."; + elf_flags = elf_elfheader (info.abfd)->e_flags; + + /* See if there is a .mdebug.XXX section. If there is, treat its + name as ABI information. GCC may have produced this section for + us. See the function mips_asm_file_start() in gcc/config/mips/mips.c. */ + for (note = info.abfd->sections; note != NULL; note = note->next) + { + if (strncmp (note->name, abi_sec, strlen (abi_sec)) == 0) + { + struct + { + const char * abi_name; + enum mips_abi mips_abi; + } + names [] = + { + { "abi32", MIPS_ABI_O32 }, + { "abiN32", MIPS_ABI_N32 }, + { "abi64", MIPS_ABI_O64 }, + { "abiO64", MIPS_ABI_O64 }, + { "eabi32", MIPS_ABI_EABI32 }, + { "eabi64", MIPS_ABI_EABI64 }, + { NULL, MIPS_ABI_UNKNOWN } + }; + int i; + + for (i = 0; names[i].abi_name != NULL; i++) + if (strcmp (note->name + strlen (abi_sec), names[i].abi_name) == 0) + break; + + if (names[i].abi_name == NULL) + printf_filtered ("Warning: Unrecognised MIPS ABI section '%s'\n", + note->name); + else + if ( mips_abi != MIPS_ABI_UNKNOWN + && mips_abi != names[i].mips_abi) + printf_filtered ("Warning: Multiple differing MIPS ABI sections\n"); else ! mips_abi = names[i].mips_abi; ! } ! } ! } + if (mips_abi == MIPS_ABI_UNKNOWN) + { /* Check ELF_FLAGS to see if it specifies the ABI being used. */ switch ((elf_flags & EF_MIPS_ABI)) { *************** mips_gdbarch_init (struct gdbarch_info i *** 3845,3850 **** - --- 3889,3895 ---- mips_abi = MIPS_ABI_UNKNOWN; break; } + } /* Try the architecture for any hint of the corect ABI */ if (mips_abi == MIPS_ABI_UNKNOWN *************** mips_gdbarch_init (struct gdbarch_info i *** 4010,4016 **** and not all gcc targets support that currently. Therefore using this flag to detect 32-bit mode would do the wrong thing given the current gcc - it would make GDB treat these 64-bit programs ! as 32-bit programs by default. */ /* enable/disable the MIPS FPU */ if (!mips_fpu_type_auto) - --- 4055,4066 ---- and not all gcc targets support that currently. Therefore using this flag to detect 32-bit mode would do the wrong thing given the current gcc - it would make GDB treat these 64-bit programs ! as 32-bit programs by default. ! ! FIXED: nickc/2000-08-08: GCC now creates a special, empty section ! whoes name indicates the ABI that is in used. There is now code ! at the start of this funciton to detect this section and set up the ! ABI selection appropriately. */ /* enable/disable the MIPS FPU */ if (!mips_fpu_type_auto)