* [PATCH RFA] solib-svr4.c patch for dynamic executables
@ 2000-11-03 17:23 Kevin Buettner
2000-11-07 13:16 ` Jim Blandy
0 siblings, 1 reply; 3+ messages in thread
From: Kevin Buettner @ 2000-11-03 17:23 UTC (permalink / raw)
To: Jim Blandy, gdb-patches; +Cc: Ulrich Drepper
The patch below is based on some patches from Ulrich Drepper that
were previously posted to this and other forums.
These patches make it possible to debug executables (on Linux and
other SVR4-like systems) in which the program is loaded at an address
different than the one given by the executable's symbolic information.
As indicated in the comments in the patch, it is likely that this code
will only be useful for debugging dynamic linkers since the code makes
sure that there is no .interp section prior to attempting to do any
relocations. (Though I suppose it's possible that it would work on a
statically linked binary which ended up being relocated for some
reason also.)
I was hoping to arrive at a more generic solution, but after working
on some similar functionality for AIX5, I've concluded that the
mechanisms for determining which sections need to be relocated and by
how much is very much target dependent. When I compare the code
below with the code that I wrote for AIX5, there seems to be very
little in common aside from the bit about allocating an array
of section_offset structs and then later calling objfile_relocate()
with section_offsets filled in as appropriate.
Anyway... I've done some limited testing of the patch below on
Linux/x86 (Red Hat 6.2 and 7.0) with /lib/ld-linux.so.2 and it
works for me; it's even possible to rerun the program again.
(I wish I could get the dynamic linker to load at a different
locations on subsequent runs; I think this should work, but have
been unable to test it.) Also, I've asked Ulrich to test these
changes (who better?) and he reports that they work fine for him.
Finally, I've run the gdb testsuite on Linux/x86 and see no
regressions. (However, someone's changes in the last couple of days
has made the number of FAILs creep up to 16 from 14 on my machine.)
Okay to commit?
Changes based on patch from Ulrich Drepper:
* solib-svr4.c (svr4_relocate_main_executable): New function.
(svr4_solib_create_inferior_hook): Call
svr4_relocate_main_executable.
Index: solib-svr4.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-svr4.c,v
retrieving revision 1.2
diff -u -p -r1.2 solib-svr4.c
--- solib-svr4.c 2000/10/30 23:31:17 1.2
+++ solib-svr4.c 2000/11/03 23:22:03
@@ -1437,6 +1437,54 @@ svr4_special_symbol_handling (void)
#endif /* !SVR4_SHARED_LIBS */
}
+/* Relocate the main executable. This function should be called
+ upon stopping the inferior process at the entry point to the
+ program. The entry point from BFD is compared to the PC and
+ if they are different, the main executable is relocated by
+ the proper amount.
+
+ This code is somewhat naive in that it assumes that each
+ section needs to be relocated by the same amount.
+
+ Also, as written it will only attempt to relocate executables
+ which lack interpreter sections. It seems likely that only
+ dynamic linker executables will get relocated. */
+
+static void
+svr4_relocate_main_executable (void)
+{
+ asection *interp_sect;
+ CORE_ADDR pc = read_pc ();
+
+ interp_sect = bfd_get_section_by_name (exec_bfd, ".interp");
+ if (interp_sect == NULL && bfd_get_start_address (exec_bfd) != pc)
+ {
+ struct cleanup *old_chain;
+ struct section_offsets *new_offsets;
+ int i, changed;
+ CORE_ADDR displacement;
+
+ displacement = pc - bfd_get_start_address (exec_bfd);
+ changed = 0;
+
+ new_offsets = xcalloc (sizeof (struct section_offsets),
+ symfile_objfile->num_sections);
+ old_chain = make_cleanup (free, new_offsets);
+
+ for (i = 0; i < symfile_objfile->num_sections; i++)
+ {
+ if (displacement != ANOFFSET (symfile_objfile->section_offsets, i))
+ changed = 1;
+ new_offsets->offsets[i] = displacement;
+ }
+
+ if (changed)
+ objfile_relocate (symfile_objfile, new_offsets);
+
+ do_cleanups (old_chain);
+ }
+}
+
/*
GLOBAL FUNCTION
@@ -1489,9 +1537,12 @@ svr4_special_symbol_handling (void)
Also, what if child has exit()ed? Must exit loop somehow.
*/
-void
+static void
svr4_solib_create_inferior_hook (void)
{
+ /* Relocate the main executable if necessary. */
+ svr4_relocate_main_executable ();
+
/* If we are using the BKPT_AT_SYMBOL code, then we don't need the base
yet. In fact, in the case of a SunOS4 executable being run on
Solaris, we can't get it yet. current_sos will get it when it needs
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH RFA] solib-svr4.c patch for dynamic executables
2000-11-03 17:23 [PATCH RFA] solib-svr4.c patch for dynamic executables Kevin Buettner
@ 2000-11-07 13:16 ` Jim Blandy
[not found] ` <1001108013427.ZM19910@ocotillo.lan>
0 siblings, 1 reply; 3+ messages in thread
From: Jim Blandy @ 2000-11-07 13:16 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches, Ulrich Drepper
The way this patch decides whether or not to relocate the main
executable seems questionable to me. It looks like we're basing our
decision on conditions which are suggestive, but not definitive.
We should look at the ABI to see what rules `exec' follows to decide
whether to relocate the main executable, and then make GDB use the
same rules.
At the very least, the test for the ".interp" section should be
explained.
Kevin Buettner <kevinb@cygnus.com> writes:
>
> The patch below is based on some patches from Ulrich Drepper that
> were previously posted to this and other forums.
>
> These patches make it possible to debug executables (on Linux and
> other SVR4-like systems) in which the program is loaded at an address
> different than the one given by the executable's symbolic information.
>
> As indicated in the comments in the patch, it is likely that this code
> will only be useful for debugging dynamic linkers since the code makes
> sure that there is no .interp section prior to attempting to do any
> relocations. (Though I suppose it's possible that it would work on a
> statically linked binary which ended up being relocated for some
> reason also.)
>
> I was hoping to arrive at a more generic solution, but after working
> on some similar functionality for AIX5, I've concluded that the
> mechanisms for determining which sections need to be relocated and by
> how much is very much target dependent. When I compare the code
> below with the code that I wrote for AIX5, there seems to be very
> little in common aside from the bit about allocating an array
> of section_offset structs and then later calling objfile_relocate()
> with section_offsets filled in as appropriate.
>
> Anyway... I've done some limited testing of the patch below on
> Linux/x86 (Red Hat 6.2 and 7.0) with /lib/ld-linux.so.2 and it
> works for me; it's even possible to rerun the program again.
> (I wish I could get the dynamic linker to load at a different
> locations on subsequent runs; I think this should work, but have
> been unable to test it.) Also, I've asked Ulrich to test these
> changes (who better?) and he reports that they work fine for him.
>
> Finally, I've run the gdb testsuite on Linux/x86 and see no
> regressions. (However, someone's changes in the last couple of days
> has made the number of FAILs creep up to 16 from 14 on my machine.)
>
> Okay to commit?
>
> Changes based on patch from Ulrich Drepper:
> * solib-svr4.c (svr4_relocate_main_executable): New function.
> (svr4_solib_create_inferior_hook): Call
> svr4_relocate_main_executable.
>
> Index: solib-svr4.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/solib-svr4.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 solib-svr4.c
> --- solib-svr4.c 2000/10/30 23:31:17 1.2
> +++ solib-svr4.c 2000/11/03 23:22:03
> @@ -1437,6 +1437,54 @@ svr4_special_symbol_handling (void)
> #endif /* !SVR4_SHARED_LIBS */
> }
>
> +/* Relocate the main executable. This function should be called
> + upon stopping the inferior process at the entry point to the
> + program. The entry point from BFD is compared to the PC and
> + if they are different, the main executable is relocated by
> + the proper amount.
> +
> + This code is somewhat naive in that it assumes that each
> + section needs to be relocated by the same amount.
> +
> + Also, as written it will only attempt to relocate executables
> + which lack interpreter sections. It seems likely that only
> + dynamic linker executables will get relocated. */
> +
> +static void
> +svr4_relocate_main_executable (void)
> +{
> + asection *interp_sect;
> + CORE_ADDR pc = read_pc ();
> +
> + interp_sect = bfd_get_section_by_name (exec_bfd, ".interp");
> + if (interp_sect == NULL && bfd_get_start_address (exec_bfd) != pc)
> + {
> + struct cleanup *old_chain;
> + struct section_offsets *new_offsets;
> + int i, changed;
> + CORE_ADDR displacement;
> +
> + displacement = pc - bfd_get_start_address (exec_bfd);
> + changed = 0;
> +
> + new_offsets = xcalloc (sizeof (struct section_offsets),
> + symfile_objfile->num_sections);
> + old_chain = make_cleanup (free, new_offsets);
> +
> + for (i = 0; i < symfile_objfile->num_sections; i++)
> + {
> + if (displacement != ANOFFSET (symfile_objfile->section_offsets, i))
> + changed = 1;
> + new_offsets->offsets[i] = displacement;
> + }
> +
> + if (changed)
> + objfile_relocate (symfile_objfile, new_offsets);
> +
> + do_cleanups (old_chain);
> + }
> +}
> +
> /*
>
> GLOBAL FUNCTION
> @@ -1489,9 +1537,12 @@ svr4_special_symbol_handling (void)
> Also, what if child has exit()ed? Must exit loop somehow.
> */
>
> -void
> +static void
> svr4_solib_create_inferior_hook (void)
> {
> + /* Relocate the main executable if necessary. */
> + svr4_relocate_main_executable ();
> +
> /* If we are using the BKPT_AT_SYMBOL code, then we don't need the base
> yet. In fact, in the case of a SunOS4 executable being run on
> Solaris, we can't get it yet. current_sos will get it when it needs
>
>
From jimb@zwingli.cygnus.com Tue Nov 07 13:51:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Andrei Petrov <and@genesyslab.com>
Cc: Nick Duffek <nsd@redhat.com>, gdb-patches@sourceware.cygnus.com, cagney@redhat.com
Subject: Re: gdb under solaris7
Date: Tue, 07 Nov 2000 13:51:00 -0000
Message-id: <npvgtz8n7y.fsf@zwingli.cygnus.com>
References: <Pine.GSO.4.10.10011071155420.507-100000@muppet>
X-SW-Source: 2000-11/msg00074.html
Content-length: 2589
We'd definitely like to use this patch. We'll need you to assign your
copyright interest this patch to the Free Software Foundation. I'll
send you the details in private mail.
(I've asked Stallman if we really need the assignment for a mostly
mechanical patch like this; it might not be necessary. However, it
probably will, so let's get the paperwork rolling now.)
> uh, I didn't think it might get into.
> Glad because it might help somebody.
>
> On Tue, 7 Nov 2000, Nick Duffek wrote:
>
> > On 30-Aug-2000, Andrei Petrov wrote:
> >
> > >The patch below lets to build gdb with SUNWspro cc compiler.
> >
> > Thanks. Speaking as a Solaris/x86 maintainer, I approve of the
> > sol-thread.c part for Solaris/x86. I have some comments on the rest,
> > which you can feel free to ignore since I can't approve or disapprove
> > it. :-)
> >
> > In various files:
> > >! char raw_buffer[MAX_REGISTER_RAW_SIZE];
> > [...]
> > >! char *raw_buffer = alloca(MAX_REGISTER_RAW_SIZE);
> >
> > All of those changes look right to me.
> >
> > remote.c:
> > >! scan = (char *) ref;
> > [...]
> > >! scan = (unsigned char *) ref;
> >
> > Looks right.
> >
> > remote.c:
> > >! pkt = unpack_int (pkt, &tag); /* tag */
> > [...]
> > >! pkt = unpack_int (pkt, (int *)&tag); /* tag */
> >
> > How about declaring tag as an int instead? Better not to use typecasts
> > when easily avoidable, I think. Andrew?
> >
> > remote.c:
> > >! p = (unsigned char *) bfd_get_section_name (abfd, sect);
> > [...]
> > >! p = (char *) bfd_get_section_name (abfd, sect);
> >
> > Yup.
> >
> > sparc-tdep.c:
> > >! sparc_software_single_step (enum target_signal ignore, /* pid, but we don't need it */
> > [...]
> > >! sparc_software_single_step (/*enum target_signal*/ uint ignore, /* pid, but we don't need it */
> >
> > What's the reason for this change?
>
> I couldn't get it compiled without this change as far as I remember,
> I don't think I tried to get proper thing for this one.
> It hard to get motivited when you see argument named ignore:-).
>
> >
> > sparc-tdep.c:
> > >! static LONGEST call_dummy_64[] =
> > [...]
> > >! static unsigned LONGEST call_dummy_64[] =
> >
> > Is the compiler complaining about the values being too big for signed long
> > long? I suggest ULONGEST instead of unsigned LONGEST along with a comment
> > explaining the reason for the change.
> Yes, I just didn't understand the reason for compiler's complain.
> I didn't find ULONGEST so the change.
>
> >
> > Nick Duffek
> > nsd@redhat.com
> >
> Regards,
> Andrey
>
>
From cgf@redhat.com Tue Nov 07 13:56:00 2000
From: Christopher Faylor <cgf@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [RFA] 'set step-mode' to control the step command.
Date: Tue, 07 Nov 2000 13:56:00 -0000
Message-id: <20001107165605.A12474@redhat.com>
References: <20001106144634.A4632@redhat.com> <14855.5477.538483.447944@kwikemart.cygnus.com> <20001106170332.A5533@redhat.com>
X-SW-Source: 2000-11/msg00075.html
Content-length: 8846
On Mon, Nov 06, 2000 at 05:03:32PM -0500, Christopher Faylor wrote:
>So, I will submit a revised patch with a enum'ized step_over_calls but keep
>the step_stop_if_no_debug, if that is ok.
And, here it is. There were no regressions with this patch.
I haven't added a test suite entry for this but it is coming.
Is this ok?
cgf
2000-11-07 Christopher Faylor <cgf@cygnus.com>
* inferior.h (step_over_calls_kind): New enum to clarify values in step_over_calls.
* infcmd.c (step_over_calls): Change definition.
(step_1): Use new enum values in relation to step_over_calls.
(step_once): Ditto.
(until_next_command): Ditto.
* infrun.c (clear_proceed_status): Ditto.
(handle_inferior_event): Ditto.
2000-11-06 Stephane Carrez <Stephane.Carrez@sun.com>
* inferior.h (step_stop_if_no_debug): New variable.
* infrun.c (step_stop_if_no_debug): Declare.
(handle_inferior_event): Stop the step command if we entered a function
without line info.
(_initialize_infrun): New command 'set step-mode' to control the step
command.
* infcmd.c (step_once): Switch to stepi mode if there is no line info
(and switching is enabled).
Index: infcmd.c
===================================================================
RCS file: /cvs/uberbaum/gdb/infcmd.c,v
retrieving revision 1.12
diff -u -p -r1.12 infcmd.c
--- infcmd.c 2000/10/30 15:32:51 1.12
+++ infcmd.c 2000/11/07 06:28:06
@@ -178,12 +178,8 @@ CORE_ADDR step_frame_address;
CORE_ADDR step_sp;
-/* 1 means step over all subroutine calls.
- 0 means don't step over calls (used by stepi).
- -1 means step over calls to undebuggable functions. */
+enum step_over_calls_kind step_over_calls;
-int step_over_calls;
-
/* If stepping, nonzero means step count is > 1
so don't print frame next time inferior stops
if it stops due to stepping. */
@@ -513,11 +509,11 @@ which has no line number information.\n"
/* It is stepi.
Don't step over function calls, not even to functions lacking
line numbers. */
- step_over_calls = 0;
+ step_over_calls = STEP_OVER_NONE;
}
if (skip_subroutines)
- step_over_calls = 1;
+ step_over_calls = STEP_OVER_ALL;
step_multi = (count > 1);
proceed ((CORE_ADDR) -1, TARGET_SIGNAL_DEFAULT, 1);
@@ -607,7 +603,13 @@ step_once (int skip_subroutines, int sin
if (!single_inst)
{
find_pc_line_pc_range (stop_pc, &step_range_start, &step_range_end);
- if (step_range_end == 0)
+
+ /* If we have no line info, switch to stepi mode. */
+ if (step_range_end == 0 && step_stop_if_no_debug)
+ {
+ step_range_start = step_range_end = 1;
+ }
+ else if (step_range_end == 0)
{
char *name;
if (find_pc_partial_function (stop_pc, &name, &step_range_start,
@@ -628,11 +630,11 @@ which has no line number information.\n"
/* It is stepi.
Don't step over function calls, not even to functions lacking
line numbers. */
- step_over_calls = 0;
+ step_over_calls = STEP_OVER_NONE;
}
if (skip_subroutines)
- step_over_calls = 1;
+ step_over_calls = STEP_OVER_ALL;
step_multi = (count > 1);
arg1 =
@@ -958,7 +960,7 @@ until_next_command (int from_tty)
step_range_end = sal.end;
}
- step_over_calls = 1;
+ step_over_calls = STEP_OVER_ALL;
step_frame_address = FRAME_FP (frame);
step_sp = read_sp ();
Index: inferior.h
===================================================================
RCS file: /cvs/uberbaum/gdb/inferior.h,v
retrieving revision 1.11
diff -u -p -r1.11 inferior.h
--- inferior.h 2000/08/01 14:48:01 1.11
+++ inferior.h 2000/11/07 06:28:06
@@ -125,6 +125,11 @@ extern void clear_proceed_status (void);
extern void proceed (CORE_ADDR, enum target_signal, int);
+/* When set, stop the 'step' command if we enter a function which has
+ no line number information. The normal behavior is that we step
+ over such function. */
+extern int step_stop_if_no_debug;
+
extern void kill_inferior (void);
extern void generic_mourn_inferior (void);
@@ -335,7 +340,12 @@ extern CORE_ADDR step_sp;
/* 1 means step over all subroutine calls.
-1 means step over calls to undebuggable functions. */
-extern int step_over_calls;
+enum step_over_calls_kind
+ {
+ STEP_OVER_NONE,
+ STEP_OVER_ALL,
+ STEP_OVER_UNDEBUGGABLE,
+ } step_over_calls;
/* If stepping, nonzero means step count is > 1
so don't print frame next time inferior stops
Index: infrun.c
===================================================================
RCS file: /cvs/uberbaum/gdb/infrun.c,v
retrieving revision 1.20
diff -u -p -r1.20 infrun.c
--- infrun.c 2000/10/30 15:32:51 1.20
+++ infrun.c 2000/11/07 06:28:06
@@ -84,6 +84,11 @@ void _initialize_infrun (void);
int inferior_ignoring_startup_exec_events = 0;
int inferior_ignoring_leading_exec_events = 0;
+/* When set, stop the 'step' command if we enter a function which has
+ no line number information. The normal behavior is that we step
+ over such function. */
+int step_stop_if_no_debug = 0;
+
/* In asynchronous mode, but simulating synchronous execution. */
int sync_execution = 0;
@@ -940,7 +945,7 @@ clear_proceed_status (void)
step_range_start = 0;
step_range_end = 0;
step_frame_address = 0;
- step_over_calls = -1;
+ step_over_calls = STEP_OVER_UNDEBUGGABLE;
stop_after_trap = 0;
stop_soon_quietly = 0;
proceed_to_finish = 0;
@@ -2612,7 +2617,7 @@ handle_inferior_event (struct execution_
loader dynamic symbol resolution code, we keep on single stepping
until we exit the run time loader code and reach the callee's
address. */
- if (step_over_calls < 0 && IN_SOLIB_DYNSYM_RESOLVE_CODE (stop_pc))
+ if (step_over_calls == STEP_OVER_UNDEBUGGABLE && IN_SOLIB_DYNSYM_RESOLVE_CODE (stop_pc))
{
CORE_ADDR pc_after_resolver = SKIP_SOLIB_RESOLVER (stop_pc);
@@ -2733,7 +2738,7 @@ handle_inferior_event (struct execution_
{
/* It's a subroutine call. */
- if (step_over_calls == 0)
+ if (step_over_calls == STEP_OVER_NONE)
{
/* I presume that step_over_calls is only 0 when we're
supposed to be stepping at the assembly language level
@@ -2744,7 +2749,7 @@ handle_inferior_event (struct execution_
return;
}
- if (step_over_calls > 0 || IGNORE_HELPER_CALL (stop_pc))
+ if (step_over_calls == STEP_OVER_ALL || IGNORE_HELPER_CALL (stop_pc))
{
/* We're doing a "next". */
@@ -2810,6 +2815,18 @@ handle_inferior_event (struct execution_
return;
}
}
+
+ /* If we have no line number and the step-stop-if-no-debug
+ is set, we stop the step so that the user has a chance to
+ switch in assembly mode. */
+ if (step_over_calls == STEP_OVER_UNDEBUGGABLE && step_stop_if_no_debug)
+ {
+ stop_step = 1;
+ print_stop_reason (END_STEPPING_RANGE, 0);
+ stop_stepping (ecs);
+ return;
+ }
+
step_over_function (ecs);
keep_going (ecs);
return;
@@ -3934,7 +3951,7 @@ struct inferior_status
CORE_ADDR step_range_start;
CORE_ADDR step_range_end;
CORE_ADDR step_frame_address;
- int step_over_calls;
+ enum step_over_calls_kind step_over_calls;
CORE_ADDR step_resume_break_address;
int stop_after_trap;
int stop_soon_quietly;
@@ -4308,5 +4325,14 @@ step == scheduler locked during every si
&setlist);
c->function.sfunc = set_schedlock_func; /* traps on target vector */
+ add_show_from_set (c, &showlist);
+
+ c = add_set_cmd ("step-mode", class_run,
+ var_boolean, (char*) &step_stop_if_no_debug,
+"Set mode of the step operation. When set, doing a step over a\n\
+function without debug line information will stop at the first\n\
+instruction of that function. Otherwise, the function is skipped and\n\
+the step command stops at a different source line.",
+ &setlist);
add_show_from_set (c, &showlist);
}
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/uberbaum/gdb/doc/gdb.texinfo,v
retrieving revision 1.28
diff -u -p -r1.28 gdb.texinfo
--- gdb.texinfo 2000/10/16 07:34:02 1.28
+++ gdb.texinfo 2000/11/07 06:28:09
@@ -3323,6 +3323,16 @@ The @code{next} command only stops at th
source line. This prevents multiple stops that could otherwise occur in
switch statements, for loops, etc.
+@kindex set step-mode
+@item set step-mode
+@itemx set step-mode on
+When stepping over functions, cause gdb to stop at the first instruction
+of a function which contains no debug line information.
+
+@itemx set step-mode off
+When stepping over functions, cause gdb to skip over any function which
+contains no debug information. This is the default.
+
@kindex finish
@item finish
Continue running until just after function in the selected stack frame
From drepper@redhat.com Tue Nov 07 14:29:00 2000
From: Ulrich Drepper <drepper@redhat.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Kevin Buettner <kevinb@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] solib-svr4.c patch for dynamic executables
Date: Tue, 07 Nov 2000 14:29:00 -0000
Message-id: <m33dh34dry.fsf@otr.mynet.cygnus.com>
References: <1001104012305.ZM6714@ocotillo.lan> <np1ywna3f4.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-11/msg00076.html
Content-length: 695
Jim Blandy <jimb@cygnus.com> writes:
> We should look at the ABI to see what rules `exec' follows to decide
> whether to relocate the main executable, and then make GDB use the
> same rules.
The rule is: binaries with e_type == ET_DYN have no fixed load address.
Don't know how to get this out of gdb data structures.
Note that this will include all DSOs but this is fine: if somebody
executes a DSO which is not prepared to do this it will crash. Just
what you expect.
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------
From jimb@zwingli.cygnus.com Tue Nov 07 15:37:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFD] objfiles.h, symfile.c, mdebugread.c: Fixes for Digital Unix.
Date: Tue, 07 Nov 2000 15:37:00 -0000
Message-id: <nplmuv8ihi.fsf@zwingli.cygnus.com>
References: <200011060732.IAA23824@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-11/msg00077.html
Content-length: 722
It seems like we're adding a bunch of members to struct objfile, and a
bunch of macros to access them, and a bunch of code to
default_symfile_offsets to initialize them, for the benefit of
a new function `sect_index_for_sc' in mdebugread.c.
It seems like it would be cleaner to simply have some mdebug-specific
code look up the offsets and fill in a table indexed by mdebug SC
number, which sect_index_for_sc could then access directly. That
would keep the entire change isolated in mdebugread.c, which is the
only reader that needs all that info. Does that sound reasonable?
Peter, I think you're more familiar with the big picture regarding the
section offset handling than I am, so I'm interested in your comments.
From jtc@redback.com Tue Nov 07 16:22:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Nick Duffek <nsd@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] target.c: target_xfer_memory_partial() returns byte count
Date: Tue, 07 Nov 2000 16:22:00 -0000
Message-id: <5mhf5jwbvw.fsf@jtc.redback.com>
References: <200011070457.eA74vkf24088@rtl.cygnus.com> <5m7l6fk4gw.fsf@jtc.redback.com>
X-SW-Source: 2000-11/msg00078.html
Content-length: 625
>>>>> "jtc" == J T Conklin <jtc@redback.com> writes:
>>>>> "Nick" == Nick Duffek <nsd@redhat.com> writes:
Nick> It looks like target_xfer_memory_partial() got broken in a recent patch.
Nick> Okay to apply this fix?
jtc> My bad. The fix looks correct.
But It's worse than I thought.
The change I committed didn't remove the code that transfer all the
memory when I cut-n-pasted to create do_xfer_memory() from the guts of
target_xfer_memory(). So at the moment, target_xfer_memory_partial()
transfers the entire region.
I'll submit a patch to fix this botch tomorrow.
--jtc
--
J.T. Conklin
RedBack Networks
From kevinb@cygnus.com Tue Nov 07 17:34:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Ulrich Drepper <drepper@redhat.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] solib-svr4.c patch for dynamic executables
Date: Tue, 07 Nov 2000 17:34:00 -0000
Message-id: <1001108013427.ZM19910@ocotillo.lan>
References: <1001104012305.ZM6714@ocotillo.lan> <np1ywna3f4.fsf@zwingli.cygnus.com> <jimb@cygnus.com>
X-SW-Source: 2000-11/msg00079.html
Content-length: 7817
On Nov 7, 4:16pm, Jim Blandy wrote:
> The way this patch decides whether or not to relocate the main
> executable seems questionable to me. It looks like we're basing our
> decision on conditions which are suggestive, but not definitive.
>
> We should look at the ABI to see what rules `exec' follows to decide
> whether to relocate the main executable, and then make GDB use the
> same rules.
See Ulrich's remark regarding the rules.
> At the very least, the test for the ".interp" section should be
> explained.
Ideally, our test for deciding whether to relocate the main executable
or not would look like this:
if (bfd_get_start_address (exec_bfd) != pc)
... /* do the relocation(s) */
That is to say, if the address at which we are stopped (which we know
is the starting location of the program) is not the same as the start
address from the ELF file, then we need to relocate the sections.
Unfortunately, this won't work because *if* there's an interpreter,
the interpreter gets executed first and will branch to the ELF file
start address after the interpreter runs. In other words, the start
address (from the executable) isn't the true start address when
there's an interepreter.
Let's explore an alternative. Ulrich's patch upon which mine is
based had a slightly different test:
if ((bfd_get_file_flags (exec_bfd) & DYNAMIC) != 0
&& bfd_get_start_address (exec_bfd) != stop_pc)
I have a hunch that this code is *practically* equivalent to my
proposed patch, but I could not convince myself of this fact. (And I
did spend quite a while trying.) I was concerned about the case where
the condition regarding the DYNAMIC flag (which is the same as
e_type == ET_DYN) being true in addition to a .interp section being
present. If this were to happen, I have no idea what the right thing
to do would be, but it would almost certainly not be to relocate
symfile_objfile by the displacement given by the difference between
the address at which gdb is stopped and the start address from the
executable; it seemed safer just to leave it alone.
I really do think that testing for the presence of an interpreter
is the correct way to make the decision about whether to relocate
or not. Think of the condition as being worded this way:
If it makes sense to compare the start addresses AND
the start addresses are different, then ...
The "makes sense to compare the start addresses" condition is
simply the test for the interpreter section being absent.
I agree that I need to explain this better in the code though. Below
is a new patch which adds a comment explaining the test for the
interpreter section. I also added a comment which explains that
relocation by a single constant is in fact mandated by the System V
ABI. I removed my former remark which said that relocating by a
single constant is naive.
I withdraw my former patch in favor of the one below.
Changes based on a patch from Ulrich Drepper:
* solib-svr4.c (svr4_relocate_main_executable): New function.
(svr4_solib_create_inferior_hook): Call
svr4_relocate_main_executable.
Index: solib-svr4.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-svr4.c,v
retrieving revision 1.2
diff -u -p -r1.2 solib-svr4.c
--- solib-svr4.c 2000/10/30 23:31:17 1.2
+++ solib-svr4.c 2000/11/08 00:57:01
@@ -1437,6 +1437,96 @@ svr4_special_symbol_handling (void)
#endif /* !SVR4_SHARED_LIBS */
}
+/* Relocate the main executable. This function should be called upon
+ stopping the inferior process at the entry point to the program.
+ The entry point from BFD is compared to the PC and if they are
+ different, the main executable is relocated by the proper amount.
+
+ As written it will only attempt to relocate executables which
+ lack interpreter sections. It seems likely that only dynamic
+ linker executables will get relocated, though it should work
+ properly for a position-independent static executable as well. */
+
+static void
+svr4_relocate_main_executable (void)
+{
+ asection *interp_sect;
+ CORE_ADDR pc = read_pc ();
+
+ /* Decide if the objfile needs to be relocated. As indicated above,
+ we will only be here when execution is stopped at the beginning
+ of the program. Relocation is necessary if the address at which
+ we are presently stopped differs from the start address stored in
+ the executable AND there's no interpreter section. The condition
+ regarding the interpreter section is very important because if
+ there *is* an interpreter section, execution will begin there
+ instead. When there is an interpreter section, the start address
+ is (presumably) used by the interpreter at some point to start
+ execution of the program.
+
+ If there is an interpreter, it is normal for it to be set to an
+ arbitrary address at the outset. The job of finding it is
+ handled in enable_break().
+
+ So, to summarize, relocations are necessary when there is no
+ interpreter section and the start address obtained from the
+ executable is different from the address at which GDB is
+ currently stopped. */
+
+ interp_sect = bfd_get_section_by_name (exec_bfd, ".interp");
+ if (interp_sect == NULL && bfd_get_start_address (exec_bfd) != pc)
+ {
+ struct cleanup *old_chain;
+ struct section_offsets *new_offsets;
+ int i, changed;
+ CORE_ADDR displacement;
+
+ /* It is necessary to relocate the objfile. The amount to
+ relocate by is simply the address at which we are stopped
+ minus the starting address from the executable.
+
+ We relocate all of the sections by the same amount. This
+ behavior is mandated by recent editions of the System V ABI.
+ According to the System V Application Binary Interface,
+ Edition 4.1, page 5-5:
+
+ ... Though the system chooses virtual addresses for
+ individual processes, it maintains the segments' relative
+ positions. Because position-independent code uses relative
+ addressesing between segments, the difference between
+ virtual addresses in memory must match the difference
+ between virtual addresses in the file. The difference
+ between the virtual address of any segment in memory and
+ the corresponding virtual address in the file is thus a
+ single constant value for any one executable or shared
+ object in a given process. This difference is the base
+ address. One use of the base address is to relocate the
+ memory image of the program during dynamic linking.
+
+ The same language also appears in Edition 4.0 of the System V
+ ABI and is left unspecified in some of the earlier editions. */
+
+ displacement = pc - bfd_get_start_address (exec_bfd);
+ changed = 0;
+
+ new_offsets = xcalloc (sizeof (struct section_offsets),
+ symfile_objfile->num_sections);
+ old_chain = make_cleanup (free, new_offsets);
+
+ for (i = 0; i < symfile_objfile->num_sections; i++)
+ {
+ if (displacement != ANOFFSET (symfile_objfile->section_offsets, i))
+ changed = 1;
+ new_offsets->offsets[i] = displacement;
+ }
+
+ if (changed)
+ objfile_relocate (symfile_objfile, new_offsets);
+
+ do_cleanups (old_chain);
+ }
+}
+
/*
GLOBAL FUNCTION
@@ -1489,9 +1579,12 @@ svr4_special_symbol_handling (void)
Also, what if child has exit()ed? Must exit loop somehow.
*/
-void
+static void
svr4_solib_create_inferior_hook (void)
{
+ /* Relocate the main executable if necessary. */
+ svr4_relocate_main_executable ();
+
/* If we are using the BKPT_AT_SYMBOL code, then we don't need the base
yet. In fact, in the case of a SunOS4 executable being run on
Solaris, we can't get it yet. current_sos will get it when it needs
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH RFA] solib-svr4.c patch for dynamic executables
[not found] ` <1001108013427.ZM19910@ocotillo.lan>
@ 2000-11-08 12:35 ` Jim Blandy
0 siblings, 0 replies; 3+ messages in thread
From: Jim Blandy @ 2000-11-08 12:35 UTC (permalink / raw)
To: Kevin Buettner; +Cc: Jim Blandy, Ulrich Drepper, gdb-patches
The comparison of the executable's PC with the new process's PC seems
fragile to me. We already know of two cases where this can happen
(interpreters and dynamic executables); I wonder whether more will
appear in the future.
How would you feel about including *both* tests in
svr4_relocate_main_executable --- both testing for a .interp section,
and testing the DYNAMIC flag?
Something like:
if (exec file is DYNAMIC
&& exec file has no .interp
&& exec file's entry PC is different from new process's PC)
then do the relocation
This would avoid testing the PC when we run non-DYNAMIC programs with
no .interp. (Which would be an old-fashioned statically linked
program, right?)
But either way, I feel I am nitpicking on shaky ground. Commit the
change, with or without my suggestion, and we'll just see what
happens.
From jimb@zwingli.cygnus.com Wed Nov 08 12:44:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: "Peter.Schauer" <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE>, Kevin Buettner <kevinb@cygnus.com>, Elena Zannoni <ezannoni@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFD] objfiles.h, symfile.c, mdebugread.c: Fixes for Digital Unix.
Date: Wed, 08 Nov 2000 12:44:00 -0000
Message-id: <np7l6e6vuc.fsf@zwingli.cygnus.com>
References: <200011080857.JAA27221@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-11/msg00103.html
Content-length: 600
[Jim suggests using obj_private to cache pointers to the sections
mdebug needs]
> That's what I meant with:
>
> : > I am not sure if adding to sect_index_* and SECT_OFF_* is the way to go in
> : > the general version, hiding those in obj_private might be
> feasible.
Okay. Kevin, Elena, what do you think?
> We would need a mdebug section index table per objfile, but I am not sure if
> obj_private is the right place. As obj_private is currently only used
> by HPPA targets, it might be safe.
obj_private looks custom-made for this case. By "HPPA targets", you
mean "SOM executables", right?
From jimb@zwingli.cygnus.com Wed Nov 08 12:45:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Reverted - June 5th patch
Date: Wed, 08 Nov 2000 12:45:00 -0000
Message-id: <np4s1i6vmp.fsf@zwingli.cygnus.com>
References: <m34s1jnpm1.fsf@dan2.cygnus.com>
X-SW-Source: 2000-11/msg00104.html
Content-length: 3935
To be clear --- this change will re-bloat GDB when handling C++ code.
We're just reverting to correct but inefficient behavior until we can
get correct and efficient behavior.
Daniel Berlin <dberlin@redhat.com> writes:
>
> As per Jim Blandy's request, I have reverted the June 5th change to
> cache type names.
> Changelog for revert patch:
> 2000-11-07 Daniel Berlin <dberlin@redhat.com>
>
> * dwarf2read.c: Revert June 5th change for caching of types,
> as per Jim Blandy's request.
>
>
> Revert patch follows:
> Index: ChangeLog
> ===================================================================
> RCS file: /cvs/src/src/gdb/ChangeLog,v
> retrieving revision 1.753
> diff -c -3 -p -r1.753 ChangeLog
> *** ChangeLog 2000/11/06 23:12:29 1.753
> --- ChangeLog 2000/11/08 02:47:34
> ***************
> *** 1,3 ****
> --- 1,8 ----
> + 2000-11-07 Daniel Berlin <dberlin@redhat.com>
> +
> + * dwarf2read.c: Revert June 5th change for caching of types,
> + as per Jim Blandy's request.
> +
> 2000-11-06 Fernando Nasser <fnasser@totem.toronto.redhat.com>
>
> * wrapper.c (gdb_value_assign): New function. Longjump-free
> Index: dwarf2read.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/dwarf2read.c,v
> retrieving revision 1.17
> diff -c -3 -p -r1.17 dwarf2read.c
> *** dwarf2read.c 2000/11/03 22:38:38 1.17
> --- dwarf2read.c 2000/11/08 02:47:35
> *************** static struct abbrev_info *dwarf2_abbrev
> *** 275,285 ****
>
> static struct die_info *die_ref_table[REF_HASH_SIZE];
>
> - #ifndef TYPE_HASH_SIZE
> - #define TYPE_HASH_SIZE 4096
> - #endif
> - static struct type *dwarf2_cached_types[TYPE_HASH_SIZE];
> -
> /* Obstack for allocating temporary storage used during symbol reading. */
> static struct obstack dwarf2_tmp_obstack;
>
> --- 275,280 ----
> *************** read_comp_unit (char *info_ptr, bfd *abf
> *** 2901,2907 ****
> char *cur_ptr;
> int nesting_level;
>
> ! /* Reset die reference table and cached types table; we are
> building new ones now. */
> dwarf2_empty_hash_tables ();
>
> --- 2896,2902 ----
> char *cur_ptr;
> int nesting_level;
>
> ! /* Reset die reference table; we are
> building new ones now. */
> dwarf2_empty_hash_tables ();
>
> *************** tag_type_to_type (struct die_info *die,
> *** 4528,4565 ****
> }
> else
> {
> ! struct attribute *attr;
> ! attr = dwarf_attr (die, DW_AT_name);
> ! if (attr && DW_STRING (attr))
> ! {
> ! char *attrname=DW_STRING (attr);
> ! unsigned long hashval=hash(attrname, strlen(attrname)) % TYPE_HASH_SIZE;
> !
> ! if (dwarf2_cached_types[hashval] != NULL)
> ! {
> ! const char *nameoftype;
> ! nameoftype = TYPE_NAME(dwarf2_cached_types[hashval]) == NULL ? TYPE_TAG_NAME(dwarf2_cached_types[hashval]) : TYPE_NAME(dwarf2_cached_types[hashval]);
> ! if (strcmp(attrname, nameoftype) == 0)
> ! {
> ! die->type=dwarf2_cached_types[hashval];
> ! }
> ! else
> ! {
> ! read_type_die (die, objfile, cu_header);
> ! dwarf2_cached_types[hashval] = die->type;
> ! }
> ! }
> ! else
> ! {
> ! read_type_die (die, objfile, cu_header);
> ! dwarf2_cached_types[hashval] = die->type;
> ! }
> ! }
> ! else
> ! {
> ! read_type_die (die, objfile, cu_header);
> ! }
> !
> if (!die->type)
> {
> dump_die (die);
> --- 4523,4529 ----
> }
> else
> {
> ! read_type_die (die, objfile, cu_header);
> if (!die->type)
> {
> dump_die (die);
> *************** static void
> *** 5606,5612 ****
> dwarf2_empty_hash_tables (void)
> {
> memset (die_ref_table, 0, sizeof (die_ref_table));
> - memset (dwarf2_cached_types, 0, sizeof(dwarf2_cached_types));
> }
>
> static unsigned int
> --- 5570,5575 ----
>
>
From jtc@redback.com Wed Nov 08 13:09:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: [RFA]: Fix partial memory transfers
Date: Wed, 08 Nov 2000 13:09:00 -0000
Message-id: <5mwveegoib.fsf@jtc.redback.com>
X-SW-Source: 2000-11/msg00105.html
Content-length: 5235
I submit the enclosed patch to target.c for approval.
My recent commit to move the dcache on top of the target xfer_memory
vector introduced a bug such that target_partial_xfer_memory() would
always perform a complete transfer, which defeated the entire purpose
of that function.
The enclosed patch fixes do_xfer_memory(), the low-level function that
calls the xfer_memory vector function(s), to perform only one transfer.
The dcache already has the logic that will call do_xfer_memory multiple
times if it returns a partial transfer.
This patch also fixes up comments for the *xfer_memory* functions.
Some have been wrong/misleading for a very long time.
This patch also includes a bug fix from Nick, which caused me to look
at and fine the above bug. I'm including it in this patch because he
retracted the bug fix when I mentioned this patch was coming.
--jtc
2000-11-08 J.T. Conklin <jtc@redback.com>
* target.c (do_xfer_memory): Only perform a single memory transfer
instead of iterating to tranfer the entire region. Higher layers
are expected to call this function multiple times for partial
transfers.
(target_xfer_memory_partial): Remove unused local variables.
2000-11-07 Nick Duffek <nsd@redhat.com>
* target.c (target_xfer_memory_partial): Return bytes transferred
instead of 0.
Index: target.c
===================================================================
RCS file: /cvs/src/src/gdb/target.c,v
retrieving revision 1.14
diff -c -r1.14 target.c
*** target.c 2000/11/03 22:00:56 1.14
--- target.c 2000/11/08 20:53:15
***************
*** 837,851 ****
return target_xfer_memory (memaddr, myaddr, len, 1);
}
! /* Move memory to or from the targets. Iterate until all of it has
! been moved, if necessary. The top target gets priority; anything
! it doesn't want, is offered to the next one down, etc. Note the
! business with curlen: if an early target says "no, but I have a
! boundary overlapping this xfer" then we shorten what we offer to
! the subsequent targets so the early guy will get a chance at the
! tail before the subsequent ones do.
! Result is 0 or errno value. */
int
do_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write)
--- 837,846 ----
return target_xfer_memory (memaddr, myaddr, len, 1);
}
! /* Move memory to or from the targets. The top target gets priority;
! if it cannot handle it, it is offered to the next one down, etc.
! Result is -1 on error, or the number of bytes transfered. */
int
do_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write)
***************
*** 863,880 ****
0. */
errno = 0;
! /* The quick case is that the top target does it all. */
res = current_target.to_xfer_memory
(memaddr, myaddr, len, write, ¤t_target);
- if (res == len)
- return len;
-
- if (res > 0)
- goto bump;
- /* If res <= 0 then we call it again in the loop. Ah well. */
! while (len > 0)
{
for (item = target_stack; item; item = item->next)
{
t = item->target_ops;
--- 858,871 ----
0. */
errno = 0;
! /* The quick case is that the top target can handle the transfer. */
res = current_target.to_xfer_memory
(memaddr, myaddr, len, write, ¤t_target);
! if (res <= 0)
{
+ /* If res <= 0 then we call it again in the loop. Ah well. */
+
for (item = target_stack; item; item = item->next)
{
t = item->target_ops;
***************
*** 889,907 ****
}
if (res <= 0)
! {
! return -1;
! }
! bump:
! done += res;
! memaddr += res;
! myaddr += res;
! len -= res;
}
!
! return done;
}
static int
target_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write)
{
--- 880,897 ----
}
if (res <= 0)
! return -1;
}
!
! return res;
}
+
+ /* Perform a memory transfer. Iterate until the entire region has
+ been transfered.
+
+ Result is 0 or errno value. */
+
static int
target_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write)
{
***************
*** 936,953 ****
return 0; /* We managed to cover it all somehow. */
}
! /* Perform a partial memory transfer. */
static int
target_xfer_memory_partial (CORE_ADDR memaddr, char *myaddr, int len,
int write_p, int *err)
{
int res;
- int err_res;
- int len_res;
- struct target_ops *t;
- struct target_stack_item *item;
/* Zero length requests are ok and require no work. */
if (len == 0)
--- 926,941 ----
return 0; /* We managed to cover it all somehow. */
}
+
+ /* Perform a partial memory transfer.
! Result is -1 on error, or the number of bytes transfered. */
static int
target_xfer_memory_partial (CORE_ADDR memaddr, char *myaddr, int len,
int write_p, int *err)
{
int res;
/* Zero length requests are ok and require no work. */
if (len == 0)
***************
*** 968,974 ****
}
*err = 0;
! return 0;
}
int
--- 956,962 ----
}
*err = 0;
! return res;
}
int
--
J.T. Conklin
RedBack Networks
From drepper@redhat.com Wed Nov 08 13:25:00 2000
From: Ulrich Drepper <drepper@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Jim Blandy <jimb@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] solib-svr4.c patch for dynamic executables
Date: Wed, 08 Nov 2000 13:25:00 -0000
Message-id: <m34s1iupgf.fsf@otr.mynet.cygnus.com>
References: <1001104012305.ZM6714@ocotillo.lan> <np1ywna3f4.fsf@zwingli.cygnus.com> <m33dh34dry.fsf@otr.mynet.cygnus.com> <np4s1i8kg1.fsf@zwingli.cygnus.com> <m3lmuuxt9i.fsf@otr.mynet.cygnus.com> <1001108201004.ZM22294@ocotillo.lan>
X-SW-Source: 2000-11/msg00106.html
Content-length: 553
Kevin Buettner <kevinb@cygnus.com> writes:
> Either way, the patch currently on the table should go in since it is
> needed to handle the case of DSOs (and perhaps other executables)
> which lack an interpreter section.
It is definitely *much* better than the current situation and it is
not disturbing any other way gdb is used.
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------
From drepper@redhat.com Wed Nov 08 13:26:00 2000
From: Ulrich Drepper <drepper@redhat.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Kevin Buettner <kevinb@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] solib-svr4.c patch for dynamic executables
Date: Wed, 08 Nov 2000 13:26:00 -0000
Message-id: <m3zojatatb.fsf@otr.mynet.cygnus.com>
References: <1001104012305.ZM6714@ocotillo.lan> <np1ywna3f4.fsf@zwingli.cygnus.com> <1001108013427.ZM19910@ocotillo.lan> <npbsvq6w23.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-11/msg00107.html
Content-length: 590
Jim Blandy <jimb@cygnus.com> writes:
> The comparison of the executable's PC with the new process's PC seems
> fragile to me. We already know of two cases where this can happen
> (interpreters and dynamic executables); I wonder whether more will
> appear in the future.
Why is it fragile? This is the same mechanism the ld.so is based on.
It is guaranteed to work.
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------
From kevinb@cygnus.com Wed Nov 08 13:30:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: "Peter.Schauer" <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE>, Elena Zannoni <ezannoni@cygnus.com>, Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFD] objfiles.h, symfile.c, mdebugread.c: Fixes for Digital Unix.
Date: Wed, 08 Nov 2000 13:30:00 -0000
Message-id: <1001108213023.ZM22461@ocotillo.lan>
References: <200011080857.JAA27221@reisser.regent.e-technik.tu-muenchen.de> <np7l6e6vuc.fsf@zwingli.cygnus.com> <jimb@cygnus.com>
X-SW-Source: 2000-11/msg00108.html
Content-length: 497
On Nov 8, 3:40pm, Jim Blandy wrote:
> [Jim suggests using obj_private to cache pointers to the sections
> mdebug needs]
>
> > That's what I meant with:
> >
> > : > I am not sure if adding to sect_index_* and SECT_OFF_* is the way to go in
> > : > the general version, hiding those in obj_private might be
> > feasible.
>
> Okay. Kevin, Elena, what do you think?
Using obj_private to keep a map from sc* indices to section indices
(or something along these lines) sounds right to me.
Kevin
From bje@redhat.com Wed Nov 08 15:12:00 2000
From: Ben Elliston <bje@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: Spelling corrections to sim-fpu.h
Date: Wed, 08 Nov 2000 15:12:00 -0000
Message-id: <200011082311.eA8NBme00638@scooby.cygnus.com>
X-SW-Source: 2000-11/msg00109.html
Content-length: 2963
FYI, I am checking in the following patch to correct some spelling
errors/typos in sim/common/sim-fpu.h.
Ben
*** sim-fpu.h 1999/04/16 01:34:57 1.1.1.1
--- sim-fpu.h 2000/11/08 23:09:55
***************
*** 164,172 ****
When converting from the sim_fpu internal type to 32/64 bit packed
format, the operation may result in a loss of precision. The
configuration macro WITH_FPU_CONVERSION controls this. By default,
! silent round to nearest is performed. Alternativly, round up,
round down and round to zero can be performed. In a simulator
! emulating exact FPU behavour, sim_fpu_round_{32,64} should be
called before packing the sim_fpu value. */
INLINE_SIM_FPU (void) sim_fpu_32to (sim_fpu *f, unsigned32 s);
--- 164,172 ----
When converting from the sim_fpu internal type to 32/64 bit packed
format, the operation may result in a loss of precision. The
configuration macro WITH_FPU_CONVERSION controls this. By default,
! silent round to nearest is performed. Alternatively, round up,
round down and round to zero can be performed. In a simulator
! emulating exact FPU behavior, sim_fpu_round_{32,64} should be
called before packing the sim_fpu value. */
INLINE_SIM_FPU (void) sim_fpu_32to (sim_fpu *f, unsigned32 s);
***************
*** 189,195 ****
INLINE_SIM_FPU (void) sim_fpu_fractionto (sim_fpu *f, int sign, int normal_exp, unsigned64 fraction, int precision);
! /* Reverse operaton. If S is a non-zero number, discards the implied
leading one and returns PRECISION fraction bits. No rounding is
performed. */
INLINE_SIM_FPU (unsigned64) sim_fpu_tofraction (const sim_fpu *s, int precision);
--- 189,195 ----
INLINE_SIM_FPU (void) sim_fpu_fractionto (sim_fpu *f, int sign, int normal_exp, unsigned64 fraction, int precision);
! /* Reverse operation. If S is a non-zero number, discards the implied
leading one and returns PRECISION fraction bits. No rounding is
performed. */
INLINE_SIM_FPU (unsigned64) sim_fpu_tofraction (const sim_fpu *s, int precision);
***************
*** 210,216 ****
! /* Arrithmetic operators.
FIXME: In the future, additional arguments ROUNDING and BITSIZE may
be added. */
--- 210,216 ----
! /* Arithmetic operators.
FIXME: In the future, additional arguments ROUNDING and BITSIZE may
be added. */
***************
*** 283,289 ****
/* Conversion of internal sim_fpu type to host double format.
! For debuging/tracing only. A SNaN is never returned. */
/* INLINE_SIM_FPU (float) sim_fpu_2f (const sim_fpu *f); */
INLINE_SIM_FPU (double) sim_fpu_2d (const sim_fpu *d);
--- 283,289 ----
/* Conversion of internal sim_fpu type to host double format.
! For debugging/tracing only. A SNaN is never returned. */
/* INLINE_SIM_FPU (float) sim_fpu_2f (const sim_fpu *f); */
INLINE_SIM_FPU (double) sim_fpu_2d (const sim_fpu *d);
From bje@redhat.com Wed Nov 08 15:18:00 2000
From: Ben Elliston <bje@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: [Sim] Patch for fp constants
Date: Wed, 08 Nov 2000 15:18:00 -0000
Message-id: <200011082317.eA8NHxR00680@scooby.cygnus.com>
X-SW-Source: 2000-11/msg00110.html
Content-length: 951
Two of the pre-defined floating point constants (namely, one and two)
are incorrectly defined in sim/common/sim-fpu.c. They should have
(normalised) exponents of zero and one, respectively.
In prior consultation with Andrew Cagney, I am checking these fixes in
now. No existing simulator uses these constants.
2000-11-09 Ben Elliston <bje@redhat.com>
* sim-fpu.c (sim_fpu_one): Set exponent to 0.
(sim_fpu_two): Set exponent to 1.
diff -u -r1.1.1.2 sim-fpu.c
--- sim-fpu.c 1999/09/22 03:28:07 1.1.1.2
+++ sim-fpu.c 2000/11/08 23:15:59
@@ -2456,10 +2456,10 @@
sim_fpu_class_qnan,
};
const sim_fpu sim_fpu_one = {
- sim_fpu_class_number, 0, IMPLICIT_1, 1
+ sim_fpu_class_number, 0, IMPLICIT_1, 0
};
const sim_fpu sim_fpu_two = {
- sim_fpu_class_number, 0, IMPLICIT_1, 2
+ sim_fpu_class_number, 0, IMPLICIT_1, 1
};
const sim_fpu sim_fpu_max32 = {
sim_fpu_class_number, 0, LSMASK64 (NR_FRAC_GUARD, NR_GUARDS32), NORMAL_EXPMAX32
From msnyder@cygnus.com Wed Nov 08 15:58:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: [PATCH] spelling correction in gdbarch.
Date: Wed, 08 Nov 2000 15:58:00 -0000
Message-id: <200011082358.PAA20756@cleaver.cygnus.com>
X-SW-Source: 2000-11/msg00111.html
Content-length: 7066
2000-11-08 Michael Snyder <msnyder@cleaver.cygnus.com>
* gdbarch.sh: Spelling correction: registrary -> registry.
* gdbarch.c: Ditto.
Index: gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.47
diff -c -r1.47 gdbarch.sh
*** gdbarch.sh 2000/10/30 21:50:57 1.47
--- gdbarch.sh 2000/11/08 23:57:58
***************
*** 1470,1476 ****
cat <<EOF
! /* Keep a registrary of per-architecture data-pointers required by GDB
modules. */
struct gdbarch_data
--- 1470,1476 ----
cat <<EOF
! /* Keep a registry of per-architecture data-pointers required by GDB
modules. */
struct gdbarch_data
***************
*** 1485,1497 ****
struct gdbarch_data_registration *next;
};
! struct gdbarch_data_registrary
{
int nr;
struct gdbarch_data_registration *registrations;
};
! struct gdbarch_data_registrary gdbarch_data_registrary =
{
0, NULL,
};
--- 1485,1497 ----
struct gdbarch_data_registration *next;
};
! struct gdbarch_data_registry
{
int nr;
struct gdbarch_data_registration *registrations;
};
! struct gdbarch_data_registry gdbarch_data_registry =
{
0, NULL,
};
***************
*** 1500,1513 ****
register_gdbarch_data (gdbarch_data_ftype *init)
{
struct gdbarch_data_registration **curr;
! for (curr = &gdbarch_data_registrary.registrations;
(*curr) != NULL;
curr = &(*curr)->next);
(*curr) = XMALLOC (struct gdbarch_data_registration);
(*curr)->next = NULL;
(*curr)->init = init;
(*curr)->data = XMALLOC (struct gdbarch_data);
! (*curr)->data->index = gdbarch_data_registrary.nr++;
return (*curr)->data;
}
--- 1500,1513 ----
register_gdbarch_data (gdbarch_data_ftype *init)
{
struct gdbarch_data_registration **curr;
! for (curr = &gdbarch_data_registry.registrations;
(*curr) != NULL;
curr = &(*curr)->next);
(*curr) = XMALLOC (struct gdbarch_data_registration);
(*curr)->next = NULL;
(*curr)->init = init;
(*curr)->data = XMALLOC (struct gdbarch_data);
! (*curr)->data->index = gdbarch_data_registry.nr++;
return (*curr)->data;
}
***************
*** 1518,1526 ****
init_gdbarch_data (struct gdbarch *gdbarch)
{
struct gdbarch_data_registration *rego;
! gdbarch->nr_data = gdbarch_data_registrary.nr + 1;
gdbarch->data = xmalloc (sizeof (void*) * gdbarch->nr_data);
! for (rego = gdbarch_data_registrary.registrations;
rego != NULL;
rego = rego->next)
{
--- 1518,1526 ----
init_gdbarch_data (struct gdbarch *gdbarch)
{
struct gdbarch_data_registration *rego;
! gdbarch->nr_data = gdbarch_data_registry.nr + 1;
gdbarch->data = xmalloc (sizeof (void*) * gdbarch->nr_data);
! for (rego = gdbarch_data_registry.registrations;
rego != NULL;
rego = rego->next)
{
***************
*** 1543,1549 ****
! /* Keep a registrary of swapped data required by GDB modules. */
struct gdbarch_swap
{
--- 1543,1549 ----
! /* Keep a registry of swapped data required by GDB modules. */
struct gdbarch_swap
{
***************
*** 1560,1572 ****
struct gdbarch_swap_registration *next;
};
! struct gdbarch_swap_registrary
{
int nr;
struct gdbarch_swap_registration *registrations;
};
! struct gdbarch_swap_registrary gdbarch_swap_registrary =
{
0, NULL,
};
--- 1560,1572 ----
struct gdbarch_swap_registration *next;
};
! struct gdbarch_swap_registry
{
int nr;
struct gdbarch_swap_registration *registrations;
};
! struct gdbarch_swap_registry gdbarch_swap_registry =
{
0, NULL,
};
***************
*** 1577,1583 ****
gdbarch_swap_ftype *init)
{
struct gdbarch_swap_registration **rego;
! for (rego = &gdbarch_swap_registrary.registrations;
(*rego) != NULL;
rego = &(*rego)->next);
(*rego) = XMALLOC (struct gdbarch_swap_registration);
--- 1577,1583 ----
gdbarch_swap_ftype *init)
{
struct gdbarch_swap_registration **rego;
! for (rego = &gdbarch_swap_registry.registrations;
(*rego) != NULL;
rego = &(*rego)->next);
(*rego) = XMALLOC (struct gdbarch_swap_registration);
***************
*** 1593,1599 ****
{
struct gdbarch_swap_registration *rego;
struct gdbarch_swap **curr = &gdbarch->swap;
! for (rego = gdbarch_swap_registrary.registrations;
rego != NULL;
rego = rego->next)
{
--- 1593,1599 ----
{
struct gdbarch_swap_registration *rego;
struct gdbarch_swap **curr = &gdbarch->swap;
! for (rego = gdbarch_swap_registry.registrations;
rego != NULL;
rego = rego->next)
{
***************
*** 1632,1638 ****
}
! /* Keep a registrary of the architectures known by GDB. */
struct gdbarch_registration
{
--- 1632,1638 ----
}
! /* Keep a registry of the architectures known by GDB. */
struct gdbarch_registration
{
***************
*** 1643,1649 ****
struct gdbarch_registration *next;
};
! static struct gdbarch_registration *gdbarch_registrary = NULL;
static void
append_name (const char ***buf, int *nr, const char *name)
--- 1643,1649 ----
struct gdbarch_registration *next;
};
! static struct gdbarch_registration *gdbarch_registry = NULL;
static void
append_name (const char ***buf, int *nr, const char *name)
***************
*** 1664,1670 ****
int nr_arches = 0;
const char **arches = NULL;
struct gdbarch_registration *rego;
! for (rego = gdbarch_registrary;
rego != NULL;
rego = rego->next)
{
--- 1664,1670 ----
int nr_arches = 0;
const char **arches = NULL;
struct gdbarch_registration *rego;
! for (rego = gdbarch_registry;
rego != NULL;
rego = rego->next)
{
***************
*** 1703,1709 ****
internal_error ("gdbarch: Attempt to register unknown architecture (%d)", bfd_architecture);
}
/* Check that we haven't seen this architecture before */
! for (curr = &gdbarch_registrary;
(*curr) != NULL;
curr = &(*curr)->next)
{
--- 1703,1709 ----
internal_error ("gdbarch: Attempt to register unknown architecture (%d)", bfd_architecture);
}
/* Check that we haven't seen this architecture before */
! for (curr = &gdbarch_registry;
(*curr) != NULL;
curr = &(*curr)->next)
{
***************
*** 1800,1806 ****
/* A default for abfd? */
/* Find the target that knows about this architecture. */
! for (rego = gdbarch_registrary;
rego != NULL;
rego = rego->next)
if (rego->bfd_architecture == info.bfd_architecture)
--- 1800,1806 ----
/* A default for abfd? */
/* Find the target that knows about this architecture. */
! for (rego = gdbarch_registry;
rego != NULL;
rego = rego->next)
if (rego->bfd_architecture == info.bfd_architecture)
From ac131313@cygnus.com Wed Nov 08 22:47:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Volker Borchert <bt@teknon.de>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [patch] Fix --target=vax-dec-vms5.5; Was: [Bug-gdb] gdb-5.0: cross build for VAX on Solaris fails (patch included)
Date: Wed, 08 Nov 2000 22:47:00 -0000
Message-id: <3A0A46D4.31BAFED7@cygnus.com>
References: <200011081302.eA8D2EU17717@Iapetos.teknon.de>
X-SW-Source: 2000-11/msg00112.html
Content-length: 2097
FYI,
I've checked in the attatched which fixes a number of errors/warnings
for the target vax-dec-vms5.5. I don't know if it actually works :-)
Andrew
Thu Nov 9 17:16:29 2000 Andrew Cagney <cagney@b1.cygnus.com>
* MAINTAINERS: Specify the vax-dec-vms5.5 target tupple.
* vax-tdep.c: Include "gdbcore.h", "frame.h" and "value.h".
(vax_print_insn): Change ``d'' to a const char pointer.
Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.53
diff -p -r1.53 MAINTAINERS
*** MAINTAINERS 2000/10/20 08:21:45 1.53
--- MAINTAINERS 2000/11/09 06:37:17
*************** maintainer works with the native maintai
*** 92,98 ****
tic80 maintenance only (tic80-coff)
v850 maintenance only (v850-elf)
! vax maintenance only (?)
w65 maintenance only (?)
z8k maintenance only (?)
--- 92,98 ----
tic80 maintenance only (tic80-coff)
v850 maintenance only (v850-elf)
! vax maintenance only (vax-dec-vms5.5)
w65 maintenance only (?)
z8k maintenance only (?)
Index: vax-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/vax-tdep.c,v
retrieving revision 1.2
diff -p -r1.2 vax-tdep.c
*** vax-tdep.c 2000/07/30 01:48:28 1.2
--- vax-tdep.c 2000/11/09 06:37:19
***************
*** 21,26 ****
--- 21,29 ----
#include "defs.h"
#include "symtab.h"
#include "opcode/vax.h"
+ #include "gdbcore.h"
+ #include "frame.h"
+ #include "value.h"
/* Vax instructions are never longer than this. */
#define MAXLEN 62
*************** vax_print_insn (CORE_ADDR memaddr, disas
*** 80,86 ****
unsigned char buffer[MAXLEN];
register int i;
register unsigned char *p;
! register char *d;
int status = (*info->read_memory_func) (memaddr, buffer, MAXLEN, info);
if (status != 0)
--- 83,89 ----
unsigned char buffer[MAXLEN];
register int i;
register unsigned char *p;
! const char *d;
int status = (*info->read_memory_func) (memaddr, buffer, MAXLEN, info);
if (status != 0)
From ac131313@cygnus.com Wed Nov 08 23:25:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: gdb-patches@sources.redhat.com, Philip Blundell <philb@gnu.org>
Subject: Re: disable gdbserver for cross builds
Date: Wed, 08 Nov 2000 23:25:00 -0000
Message-id: <3A0A4FE0.1C31355E@cygnus.com>
References: <E13bpBo-0004H7-00@kings-cross.london.uk.eu.org> <013701c02c27$955caf80$LocalHost@netbackup>
X-SW-Source: 2000-11/msg00113.html
Content-length: 3437
I think there are several cases where gdbserver could be configured:
--build=X --host=X --target=X
For X using procfs/ptrace
Native debugger
--build=X --host=X --target=Y
For Y using libsim.a
Cross debugger
--build=X --host=Y --target=Y
For Y using procfs/ptrace
Canadian cross of native debugger
--build=X --host=Y --target=Z
For Z using libsim.a
Canadian cross of cross debugger
I don't think that the configury should be trying to do things like:
--build=X --host=X --target=Y
For Y using procfs/ptrace
Some people call this host-X-host
A host=X/target=Y procfs/ptrace gdbserver couldn't do anything useful
(well I guess you could NFS mount Y's /proc :-). A host=Y/target=Y
procfs/ptrace gdbserver is counter-intuitive, it is better handled by
the user expalicitly configuring/building a canadian-cross.
I should note that in a number of the above cases
(build=X/host=Y/target=Y and build=X/host=Y/target=Z) there is the
potential for building both a procfs/ptrace and libsim gdbserver
(example would be ppc-linux).
So I guess the two things to do are:
o reach consensus on which of the
above are useful
o fix the configury to match
I should also mention that gdbserver is heading for a period when it is
going to struggle to survive - multi-arch makes it difficult to build a
traditional gdbserver.
Scott Bambrough wrote:
> [...]
> I should be able to add gdbserver to configdirs in configure.tgt, and have
> it built automatically. This used to work AFAIK. Somewhere along the line,
> it got broken. Don't know how, or when, and I really don't care. The
> configdirs macro from configure.tgt is never used to configure any
> subdirectories AFAICT. I think this is wrong; it prevents gdbserver from
> being built for any target that adds it to configdirs, it prevents the
> rdi-share directory from being configured automatically for embedded arm
> targets and the nlm directory from being configured for any netware targets.
> IMHO if building gdbserver automatically is not desired for a particular
> target, then the appropriate thing to do is to remove it from configdirs in
> configure.tgt.
I don't think that gdb/gdbserver should be configured unless the target
/ native files explicitly enable it. This is because, at present, it
isn't enabled and this will have the likely effect of breaking random
target builds :-(
>
> There is a warning in the README in the gdbserver subdirectory stating that
> it currently doesn't build in a cross-compilation environment. I don't
> think it makes sense to build other than with host=target. It has to run on
> the same environment it was built for. Thus enabling the statement that
> removes gdbserver from configdirs if host != target is a valid thing to do.
> This statement was removed to allow gdbserver to support simulators
> (ChangeLog-97). Is this currently possible? If so it needs to be
> considered.
>
> This issue has been around since July, and needs to be dealt with. I think
> there is good reason for this change, and I haven't seen any compelling
> arguments why it shouldn't be made. I've included pointers to my earlier
> RFC and my responses to questions about the patch included there.
>
> http://sources.redhat.com/ml/gdb-patches/2000-07/msg00375.html
> http://sources.redhat.com/ml/gdb-patches/2000-08/msg00007.html
> http://sources.redhat.com/ml/gdb-patches/2000-08/msg00009.html
>
enjoy,
Andrew
From Peter.Schauer@regent.e-technik.tu-muenchen.de Thu Nov 09 01:54:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] Implement auto-solib-add for AIX3/4, cleanup of shlib code.
Date: Thu, 09 Nov 2000 01:54:00 -0000
Message-id: <200011090953.KAA28740@reisser.regent.e-technik.tu-muenchen.de>
References: <1001106061910.ZM14800@ocotillo.lan>
X-SW-Source: 2000-11/msg00114.html
Content-length: 2245
Committed.
> Add auto-solib-add support for AIX, remove obsolete and unused
> SOLIB_SYMBOLS_MANUAL code, cleanup of AIX shared library handling code.
> * rs6000-nat.c (vmap_symtab): Do not try to modify offsets
> if symbols are not yet loaded.
> (vmap_add_symbols): New function to add symbols for a vmap entry.
> (add_vmap): Turn errors into warnings, return NULL vmap upon
> failure. Add symbols via vmap_add_symbols only if requested.
> (xcoff_relocate_core): Allow debugging of core files without an
> executable file. Handle NULL returns from add_vmap gracefully.
> * xcoffsolib.c (solib_add): Remove, no longer needed.
> (solib_info): Do not check for new shared libraries if there is no
> inferior process.
> (sharedlibrary_command): Made static.
> Do not check for new shared libraries if there is no inferior process.
> Add symbols for requested shared libraries via vmap_add_symbols.
> (_initialize_solib): Add `set auto-solib-add' command.
> * xcoffsolib.h (vmap_add_symbols): Add prototype declaration.
>
> * config/rs6000/tm-rs6000.h (PC_LOAD_SEGMENT): Move from here ...
> * config/rs6000/nm-rs6000.h: ... to here, this is an AIX native
> feature.
> * config/powerpc/tm-macos.h, config/powerpc/tm-ppc-eabi.h,
> config/powerpc/tm-ppc-nw.h, config/rs6000/tm-rs6000ly.h:
> Remove #undef PC_LOAD_SEGMENT.
> * config/powerpc/aix.mt, config/rs6000/aix4.mt, config/rs6000/rs6000.mt
> (TDEPFILES): Move xcoffsolib.o from here ...
> * config/powerpc/aix.mh, config/rs6000/aix4.mh, config/rs6000/rs6000.mh
> (NATDEPFILES): ... to here, xcoffsolib.o contains AIX native code
> only.
> * rs6000-tdep.c: Remove #include xcoffsolib.h, no longer needed.
> * xcoffsolib.h (xcoff_relocate_symtab_hook): Remove declaration.
> * rs6000-nat.c (_initialize_core_rs6000): Remove setting of
> xcoff_relocate_symtab_hook, no longer needed.
> * xcoffsolib.c (solib_info, sharedlibrary_command): Remove
> xcoff_relocate_symtab_hook indirection, call xcoff_relocate_symtab
> directly, as xcoffsolib.c is now compiled in native AIX configurations
> only.
> * Makefile.in: Update dependencies for rs6000-tdep.o, rs6000-nat.o
> and xcoffsolib.o.
--
Peter Schauer pes@regent.e-technik.tu-muenchen.de
From orjan.friberg@axis.com Thu Nov 09 02:21:00 2000
From: Orjan Friberg <orjan.friberg@axis.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Getting hold of a bfd in _initialize_<target>_tdep
Date: Thu, 09 Nov 2000 02:21:00 -0000
Message-id: <3A0A7A68.D285F405@axis.com>
X-SW-Source: 2000-11/msg00115.html
Content-length: 774
When defining the tm_print_insn parameter in _initialize_cris_tdep (port
to be submitted), I need a bfd (not just bfd_arch_info) to supply to a
function (cris_get_disassembler) which gives me the correct
disassembler. However, I can't seem to get hold of one. Also, no one
seems to be using the disassembler (bfd *) function in dis-asm.h, which
makes me suspicious as to its applicability. The rs6000 target does make
use of the info.abfd in its gdbarch_init () function, though I can't
verify that it's actually != 0 inside function.
Should I base the choice of disassembler on something else than the
actual bfd, or is there a proper way to get hold of it?
--
Orjan Friberg E-mail: orjan.friberg@axis.com
Axis Communications AB Phone: +46 46 272 17 68
From msnyder@redhat.com Thu Nov 09 10:25:00 2000
From: Michael Snyder <msnyder@redhat.com>
To: Orjan Friberg <orjan.friberg@axis.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Getting hold of a bfd in _initialize_<target>_tdep
Date: Thu, 09 Nov 2000 10:25:00 -0000
Message-id: <3A0AEC03.7B4E@redhat.com>
References: <3A0A7A68.D285F405@axis.com>
X-SW-Source: 2000-11/msg00116.html
Content-length: 807
Orjan Friberg wrote:
>
> When defining the tm_print_insn parameter in _initialize_cris_tdep (port
> to be submitted), I need a bfd (not just bfd_arch_info) to supply to a
> function (cris_get_disassembler) which gives me the correct
> disassembler. However, I can't seem to get hold of one. Also, no one
> seems to be using the disassembler (bfd *) function in dis-asm.h, which
> makes me suspicious as to its applicability. The rs6000 target does make
> use of the info.abfd in its gdbarch_init () function, though I can't
> verify that it's actually != 0 inside function.
>
> Should I base the choice of disassembler on something else than the
> actual bfd, or is there a proper way to get hold of it?
With appologies to the gods of software engineering,
you could use the global variable "exec_bfd".
From hans-peter.nilsson@axis.com Thu Nov 09 10:36:00 2000
From: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
To: gdb-patches@sourceware.cygnus.com
Cc: orjan.friberg@axis.com
Subject: Re: Getting hold of a bfd in _initialize_<target>_tdep
Date: Thu, 09 Nov 2000 10:36:00 -0000
Message-id: <200011091836.TAA29203@ignucius.axis.se>
References: <3A0A7A68.D285F405@axis.com>
X-SW-Source: 2000-11/msg00117.html
Content-length: 874
> Date: Thu, 09 Nov 2000 11:20:24 +0100
> From: Orjan Friberg <orjanf@axis.com>
> When defining the tm_print_insn parameter in _initialize_cris_tdep (port
> to be submitted), I need a bfd (not just bfd_arch_info) to supply to a
> function (cris_get_disassembler) which gives me the correct
> disassembler.
Let me just add that it actually *is* traits of the file format
(really: the bfd_target) that cris_get_disassembler uses:
whether or not to add register-prefix to registers depending on
symbol_leading_char.
I was obviously wrong thinking that the function disassemble
declared in include/dis-asm.h was used also by gdb (so a bfd was
handy). But somehow it just seemed natural, that for all common
cases there is a bfd somewhere close by, to use by gdb target
initialization functions. (Or that there was something that
should be fixed to do that. ;-)
brgds, H-P
From jimb@zwingli.cygnus.com Thu Nov 09 13:29:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Orjan Friberg <orjan.friberg@axis.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Getting hold of a bfd in _initialize_<target>_tdep
Date: Thu, 09 Nov 2000 13:29:00 -0000
Message-id: <npu29g4yx8.fsf@zwingli.cygnus.com>
References: <3A0A7A68.D285F405@axis.com>
X-SW-Source: 2000-11/msg00118.html
Content-length: 1038
> When defining the tm_print_insn parameter in _initialize_cris_tdep (port
> to be submitted), I need a bfd (not just bfd_arch_info) to supply to a
> function (cris_get_disassembler) which gives me the correct
> disassembler. However, I can't seem to get hold of one. Also, no one
> seems to be using the disassembler (bfd *) function in dis-asm.h, which
> makes me suspicious as to its applicability. The rs6000 target does make
> use of the info.abfd in its gdbarch_init () function, though I can't
> verify that it's actually != 0 inside function.
>
> Should I base the choice of disassembler on something else than the
> actual bfd, or is there a proper way to get hold of it?
The _initialize functions are called before GDB has opened any BFD's,
so they can't do anything smart about tm_print_insn. What you can do
instead is set tm_print_insn to point to a function in your tdep file
which calls the right function from libopcodes.a; this is what the
MIPS target does.
Shouldn't tm_print_insn be replaced with a gdbarch method?
From jtc@redback.com Thu Nov 09 14:59:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH]: Move shared library support for NetBSD targets
Date: Thu, 09 Nov 2000 14:59:00 -0000
Message-id: <5mk8acda5u.fsf@jtc.redback.com>
X-SW-Source: 2000-11/msg00119.html
Content-length: 8662
As Mike recently did for the Linux targets, I've moved shared library
objects from NATDEPFILES to TDEPFILES for the NetBSD targets.
--jtc
2000-11-09 J.T. Conklin <jtc@redback.com>
* config/i386/nbsd.mh: Remove solib.o, solib-svr4.o from NATDEPFILES.
* config/i386/nbsdelf.mh: Likewise.
* config/m68k/nbsd.mh: Likewise.
* config/ns32k/nbsd.mh: Likewise.
* config/powerpc/nbsd.mh: Likewise.
* config/sparc/nbsd.mh: Likewise.
* config/sparc/nbsdelf.mh: Likewise.
* config/i386/nbsd.mt: Add solib.o, solib-svr4.o to TDEPFILES.
* config/i386/nbsdelf.mt: Likewise.
* config/m68k/nbsd.mt: Likewise.
* config/ns32k/nbsd.mt: Likewise.
* config/powerpc/nbsd.mt: Likewise.
* config/sparc/nbsd.mt: Likewise.
Index: config/i386/nbsd.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nbsd.mh,v
retrieving revision 1.5
diff -c -r1.5 nbsd.mh
*** nbsd.mh 2000/10/24 20:05:35 1.5
--- nbsd.mh 2000/11/09 22:42:17
***************
*** 1,6 ****
# Host: Intel 386 running NetBSD
XDEPFILES=
! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o \
! i386nbsd-nat.o solib.o solib-svr4.o
XM_FILE= xm-nbsd.h
NAT_FILE= nm-nbsd.h
--- 1,5 ----
# Host: Intel 386 running NetBSD
XDEPFILES=
! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o i386nbsd-nat.o
XM_FILE= xm-nbsd.h
NAT_FILE= nm-nbsd.h
Index: config/i386/nbsd.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nbsd.mt,v
retrieving revision 1.4
diff -c -r1.4 nbsd.mt
*** nbsd.mt 2000/09/07 20:08:40 1.4
--- nbsd.mt 2000/11/09 22:42:17
***************
*** 1,5 ****
# Target: Intel 386 running NetBSD
! TDEPFILES= i386-tdep.o i387-tdep.o i386nbsd-tdep.o
TM_FILE= tm-nbsd.h
GDBSERVER_DEPFILES= low-nbsd.o
--- 1,5 ----
# Target: Intel 386 running NetBSD
! TDEPFILES= i386-tdep.o i387-tdep.o i386nbsd-tdep.o solib.o solib-svr4.o
TM_FILE= tm-nbsd.h
GDBSERVER_DEPFILES= low-nbsd.o
Index: config/i386/nbsdelf.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nbsdelf.mh,v
retrieving revision 1.3
diff -c -r1.3 nbsdelf.mh
*** nbsdelf.mh 2000/10/24 20:05:35 1.3
--- nbsdelf.mh 2000/11/09 22:42:17
***************
*** 1,6 ****
# Host: Intel 386 running NetBSD
XDEPFILES=
! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o \
! i386nbsd-nat.o solib.o solib-svr4.o
XM_FILE= xm-nbsd.h
NAT_FILE= nm-nbsdelf.h
--- 1,5 ----
# Host: Intel 386 running NetBSD
XDEPFILES=
! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o i386nbsd-nat.o
XM_FILE= xm-nbsd.h
NAT_FILE= nm-nbsdelf.h
Index: config/i386/nbsdelf.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nbsdelf.mt,v
retrieving revision 1.1
diff -c -r1.1 nbsdelf.mt
*** nbsdelf.mt 2000/06/02 23:15:28 1.1
--- nbsdelf.mt 2000/11/09 22:42:17
***************
*** 1,5 ****
# Target: Intel 386 running NetBSD
! TDEPFILES= i386-tdep.o i387-tdep.o
TM_FILE= tm-nbsdelf.h
GDBSERVER_DEPFILES= low-nbsd.o
--- 1,5 ----
# Target: Intel 386 running NetBSD
! TDEPFILES= i386-tdep.o i387-tdep.o solib.o solib-svr4.o
TM_FILE= tm-nbsdelf.h
GDBSERVER_DEPFILES= low-nbsd.o
Index: config/m68k/nbsd.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/m68k/nbsd.mh,v
retrieving revision 1.4
diff -c -r1.4 nbsd.mh
*** nbsd.mh 2000/10/24 20:05:35 1.4
--- nbsd.mh 2000/11/09 22:42:17
***************
*** 1,6 ****
# Host: Motorola m68k running NetBSD
XDEPFILES=
! NATDEPFILES= infptrace.o inftarg.o fork-child.o corelow.o \
! m68knbsd-nat.o solib.o solib-svr4.o
XM_FILE= xm-nbsd.h
NAT_FILE= nm-nbsd.h
--- 1,5 ----
# Host: Motorola m68k running NetBSD
XDEPFILES=
! NATDEPFILES= infptrace.o inftarg.o fork-child.o corelow.o m68knbsd-nat.o
XM_FILE= xm-nbsd.h
NAT_FILE= nm-nbsd.h
Index: config/m68k/nbsd.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/m68k/nbsd.mt,v
retrieving revision 1.2
diff -c -r1.2 nbsd.mt
*** nbsd.mt 2000/05/24 04:16:27 1.2
--- nbsd.mt 2000/11/09 22:42:17
***************
*** 1,3 ****
# Target: Motorola m68k running NetBSD
! TDEPFILES= m68k-tdep.o
TM_FILE= tm-nbsd.h
--- 1,3 ----
# Target: Motorola m68k running NetBSD
! TDEPFILES= m68k-tdep.o solib.o solib-svr4.o
TM_FILE= tm-nbsd.h
Index: config/ns32k/nbsd.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/ns32k/nbsd.mh,v
retrieving revision 1.4
diff -c -r1.4 nbsd.mh
*** nbsd.mh 2000/10/24 20:05:36 1.4
--- nbsd.mh 2000/11/09 22:42:17
***************
*** 1,6 ****
# Host: PC532 running NetBSD
XDEPFILES=
! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o \
! ns32knbsd-nat.o solib.o solib-svr4.o
XM_FILE= xm-nbsd.h
NAT_FILE= nm-nbsd.h
--- 1,5 ----
# Host: PC532 running NetBSD
XDEPFILES=
! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o ns32knbsd-nat.o
XM_FILE= xm-nbsd.h
NAT_FILE= nm-nbsd.h
Index: config/ns32k/nbsd.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/ns32k/nbsd.mt,v
retrieving revision 1.2
diff -c -r1.2 nbsd.mt
*** nbsd.mt 2000/05/24 04:16:27 1.2
--- nbsd.mt 2000/11/09 22:42:17
***************
*** 1,3 ****
# Target: PC532 running NetBSD
! TDEPFILES= ns32k-tdep.o
TM_FILE= tm-nbsd.h
--- 1,3 ----
# Target: PC532 running NetBSD
! TDEPFILES= ns32k-tdep.o solib.o solib-svr4.o
TM_FILE= tm-nbsd.h
Index: config/powerpc/nbsd.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/powerpc/nbsd.mh,v
retrieving revision 1.3
diff -c -r1.3 nbsd.mh
*** nbsd.mh 2000/10/24 20:05:36 1.3
--- nbsd.mh 2000/11/09 22:42:17
***************
*** 1,5 ****
# Host: PowerPC, running NetBSD
XDEPFILES=
! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o solib.o solib-svr4.o ppcnbsd-nat.o
XM_FILE= xm-nbsd.h
NAT_FILE= nm-nbsd.h
--- 1,5 ----
# Host: PowerPC, running NetBSD
XDEPFILES=
! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o ppcnbsd-nat.o
XM_FILE= xm-nbsd.h
NAT_FILE= nm-nbsd.h
Index: config/powerpc/nbsd.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/powerpc/nbsd.mt,v
retrieving revision 1.3
diff -c -r1.3 nbsd.mt
*** nbsd.mt 2000/07/31 20:56:43 1.3
--- nbsd.mt 2000/11/09 22:42:17
***************
*** 1,5 ****
# Target: PowerPC, running NetBSD
! TDEPFILES= rs6000-tdep.o ppc-linux-tdep.o
TM_FILE= tm-nbsd.h
GDBSERVER_DEPFILES= low-nbsd.o
--- 1,5 ----
# Target: PowerPC, running NetBSD
! TDEPFILES= rs6000-tdep.o ppc-linux-tdep.o solib.o solib-svr4.o
TM_FILE= tm-nbsd.h
GDBSERVER_DEPFILES= low-nbsd.o
Index: config/sparc/nbsd.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/sparc/nbsd.mh,v
retrieving revision 1.3
diff -c -r1.3 nbsd.mh
*** nbsd.mh 2000/10/24 20:05:36 1.3
--- nbsd.mh 2000/11/09 22:42:17
***************
*** 2,6 ****
XDEPFILES=
XM_FILE= xm-nbsd.h
NAT_FILE= nm-nbsd.h
! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o sparc-nat.o solib.o solib-svr4.o
HOST_IPC=-DBSD_IPC
--- 2,6 ----
XDEPFILES=
XM_FILE= xm-nbsd.h
NAT_FILE= nm-nbsd.h
! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o sparc-nat.o
HOST_IPC=-DBSD_IPC
Index: config/sparc/nbsd.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/sparc/nbsd.mt,v
retrieving revision 1.1.1.2
diff -c -r1.1.1.2 nbsd.mt
*** nbsd.mt 1999/12/14 01:05:42 1.1.1.2
--- nbsd.mt 2000/11/09 22:42:17
***************
*** 1,3 ****
# Target: Sun 4 or Sparcstation, running NetBSD
! TDEPFILES= sparc-tdep.o
TM_FILE= tm-nbsd.h
--- 1,3 ----
# Target: Sun 4 or Sparcstation, running NetBSD
! TDEPFILES= sparc-tdep.o solib.o solib-svr4.o
TM_FILE= tm-nbsd.h
Index: config/sparc/nbsdelf.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/sparc/nbsdelf.mh,v
retrieving revision 1.3
diff -c -r1.3 nbsdelf.mh
*** nbsdelf.mh 2000/10/24 20:05:36 1.3
--- nbsdelf.mh 2000/11/09 22:42:17
***************
*** 2,6 ****
XDEPFILES=
XM_FILE= xm-nbsd.h
NAT_FILE= nm-nbsdelf.h
! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o sparc-nat.o solib.o solib-svr4.o
HOST_IPC=-DBSD_IPC
--- 2,6 ----
XDEPFILES=
XM_FILE= xm-nbsd.h
NAT_FILE= nm-nbsdelf.h
! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o sparc-nat.o
HOST_IPC=-DBSD_IPC
--
J.T. Conklin
RedBack Networks
From fnasser@cygnus.com Thu Nov 09 15:36:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: Fixed 2 testsuite regressions
Date: Thu, 09 Nov 2000 15:36:00 -0000
Message-id: <3A0B34F8.A8155249@cygnus.com>
X-SW-Source: 2000-11/msg00120.html
Content-length: 5163
Just a quick fix to the pattern expected. There was no real problem.
* gdb.c++/templates.exp (test_template_breakpoints): Change Britsh
spelling "cancelled" to U.S. spelling "canceled" to match changes
made to gdb.
* gdb.c++/ovldbreak.exp: Ditto.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/ovldbreak.exp,v
retrieving revision 1.1.1.5
diff -c -p -r1.1.1.5 ovldbreak.exp
*** ovldbreak.exp 2000/02/05 07:30:00 1.1.1.5
--- ovldbreak.exp 2000/11/09 23:22:58
*************** gdb_expect {
*** 456,471 ****
-re "\\\[0\\\] cancel\r\n\\\[1\\\] all\r\n\\\[2\\\] foo::overload1arg\\(double\\)
at.*$srcfile:121\r\n\\\[3\\\] foo::overload1arg\\(float\\) at.*$srcfile:120\r\n\\\[4\\\]
foo::overload1arg\\(unsigned long\\) at.*$srcfile:119\r\n\\\[5\\\] foo::overload1arg\\(long\\)
at.*$srcfile:118\r\n\\\[6\\\] foo::overload1arg\\(unsigned int\\) at.*$srcfile:117\r\n\\\[7\\\]
foo::overload1arg\\(int\\) at.*$srcfile:116\r\n\\\[8\\\] foo::overload1arg\\(unsigned short\\)
at.*$srcfile:115\r\n\\\[9\\\] foo::overload1arg\\(short\\) at.*$srcfile:114\r\n\\\[10\\\]
foo::overload1arg\\(unsigned char\\) at.*$srcfile:113\r\n\\\[11\\\] foo::overload1arg\\(signed
char\\) at.*$srcfile:112\r\n\\\[12\\\] foo::overload1arg\\(char\\)
at.*$srcfile:111\r\n\\\[13\\\] foo::overload1arg\\(void\\) at.*$srcfile:110\r\n> $" {
send_gdb "0\n"
gdb_expect {
! -re "cancelled\r\n$gdb_prompt $" {
! pass "set bp cancelled" }
-re ".*$gdb_prompt $" {
! fail "set bp cancelled wrong bp reply" }
timeout {
! fail "(timeout)set bp cancelled wrong bp reply" }
}
}
! -re ".*$gdb_prompt $" { fail "set bp cancelled(wrong menu)" }
! timeout { fail "(timeout)set bp cancelled(wrong menu)" }
}
--- 456,471 ----
-re "\\\[0\\\] cancel\r\n\\\[1\\\] all\r\n\\\[2\\\] foo::overload1arg\\(double\\)
at.*$srcfile:121\r\n\\\[3\\\] foo::overload1arg\\(float\\) at.*$srcfile:120\r\n\\\[4\\\]
foo::overload1arg\\(unsigned long\\) at.*$srcfile:119\r\n\\\[5\\\] foo::overload1arg\\(long\\)
at.*$srcfile:118\r\n\\\[6\\\] foo::overload1arg\\(unsigned int\\) at.*$srcfile:117\r\n\\\[7\\\]
foo::overload1arg\\(int\\) at.*$srcfile:116\r\n\\\[8\\\] foo::overload1arg\\(unsigned short\\)
at.*$srcfile:115\r\n\\\[9\\\] foo::overload1arg\\(short\\) at.*$srcfile:114\r\n\\\[10\\\]
foo::overload1arg\\(unsigned char\\) at.*$srcfile:113\r\n\\\[11\\\] foo::overload1arg\\(signed
char\\) at.*$srcfile:112\r\n\\\[12\\\] foo::overload1arg\\(char\\)
at.*$srcfile:111\r\n\\\[13\\\] foo::overload1arg\\(void\\) at.*$srcfile:110\r\n> $" {
send_gdb "0\n"
gdb_expect {
! -re "canceled\r\n$gdb_prompt $" {
! pass "set bp canceled" }
-re ".*$gdb_prompt $" {
! fail "set bp canceled wrong bp reply" }
timeout {
! fail "(timeout)set bp canceled wrong bp reply" }
}
}
! -re ".*$gdb_prompt $" { fail "set bp canceled(wrong menu)" }
! timeout { fail "(timeout)set bp canceled(wrong menu)" }
}
Index: templates.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/templates.exp,v
retrieving revision 1.2
diff -c -p -r1.2 templates.exp
*** templates.exp 2000/06/05 20:47:28 1.2
--- templates.exp 2000/11/09 23:22:58
*************** proc test_template_breakpoints {} {
*** 105,116 ****
gdb_expect {
-re "0. cancel.*\[\r\n\]*.1. all.*\[\r\n\]*.2. T5<int>::T5\\(int\\) at .*\[\r\n\]*.3.
T5<int>::T5\\(T5<int> const &\\) at .*\[\r\n\]*> $" {
gdb_test "0" \
! "cancelled" \
"constructor breakpoint (obsolete format!)"
}
-re ".0. cancel\[\r\n\]*.1. all\[\r\n\]*.2. T5<int>::T5\\(T5<int> const &\\) at
.*templates.cc:.*\[\r\n\]*.3. T5<int>::T5\\(int\\) at .*templates.cc:.*\[\r\n\]*> $" {
gdb_test "0" \
! "cancelled" \
"constructor breakpoint"
}
-re ".*$gdb_prompt $" { fail "constructor breakpoint" }
--- 105,116 ----
gdb_expect {
-re "0. cancel.*\[\r\n\]*.1. all.*\[\r\n\]*.2. T5<int>::T5\\(int\\) at .*\[\r\n\]*.3.
T5<int>::T5\\(T5<int> const &\\) at .*\[\r\n\]*> $" {
gdb_test "0" \
! "canceled" \
"constructor breakpoint (obsolete format!)"
}
-re ".0. cancel\[\r\n\]*.1. all\[\r\n\]*.2. T5<int>::T5\\(T5<int> const &\\) at
.*templates.cc:.*\[\r\n\]*.3. T5<int>::T5\\(int\\) at .*templates.cc:.*\[\r\n\]*> $" {
gdb_test "0" \
! "canceled" \
"constructor breakpoint"
}
-re ".*$gdb_prompt $" { fail "constructor breakpoint" }
From kevinb@cygnus.com Thu Nov 09 17:14:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Cc: Jim Blandy <jimb@cygnus.com>, Ulrich Drepper <drepper@redhat.com>
Subject: Re: [PATCH RFA] solib-svr4.c patch for dynamic executables
Date: Thu, 09 Nov 2000 17:14:00 -0000
Message-id: <1001110011408.ZM28325@ocotillo.lan>
References: <1001104012305.ZM6714@ocotillo.lan> <np1ywna3f4.fsf@zwingli.cygnus.com> <1001108013427.ZM19910@ocotillo.lan> <kevinb@cygnus.com>
X-SW-Source: 2000-11/msg00121.html
Content-length: 2562
On Nov 7, 6:34pm, Kevin Buettner wrote:
> I withdraw my former patch in favor of the one below.
>
> Changes based on a patch from Ulrich Drepper:
> * solib-svr4.c (svr4_relocate_main_executable): New function.
> (svr4_solib_create_inferior_hook): Call
> svr4_relocate_main_executable.
Committed.
I added the additional test that Jim Blandy asked for which makes
sure that the executable is dynamic. Here are what the comments
and the code for the test look like:
/* Decide if the objfile needs to be relocated. As indicated above,
we will only be here when execution is stopped at the beginning
of the program. Relocation is necessary if the address at which
we are presently stopped differs from the start address stored in
the executable AND there's no interpreter section. The condition
regarding the interpreter section is very important because if
there *is* an interpreter section, execution will begin there
instead. When there is an interpreter section, the start address
is (presumably) used by the interpreter at some point to start
execution of the program.
If there is an interpreter, it is normal for it to be set to an
arbitrary address at the outset. The job of finding it is
handled in enable_break().
So, to summarize, relocations are necessary when there is no
interpreter section and the start address obtained from the
executable is different from the address at which GDB is
currently stopped.
[ The astute reader will note that we also test to make sure that
the executable in question has the DYNAMIC flag set. It is my
opinion that this test is unnecessary (undesirable even). It
was added to avoid inadvertent relocation of an executable
whose e_type member in the ELF header is not ET_DYN. There may
be a time in the future when it is desirable to do relocations
on other types of files as well in which case this condition
should either be removed or modified to accomodate the new file
type. (E.g, an ET_EXEC executable which has been built to be
position-independent could safely be relocated by the OS if
desired. It is true that this violates the ABI, but the ABI
has been known to be bent from time to time.) - Kevin, Nov 2000. ]
*/
interp_sect = bfd_get_section_by_name (exec_bfd, ".interp");
if (interp_sect == NULL
&& (bfd_get_file_flags (exec_bfd) & DYNAMIC) != 0
&& bfd_get_start_address (exec_bfd) != pc)
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-11-08 12:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-11-03 17:23 [PATCH RFA] solib-svr4.c patch for dynamic executables Kevin Buettner
2000-11-07 13:16 ` Jim Blandy
[not found] ` <1001108013427.ZM19910@ocotillo.lan>
2000-11-08 12:35 ` Jim Blandy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox