This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC] RE: bfd/cpu-powerpc.c, bfd/cpu-h8300.c problems (bfd_lookup_arch)


Hi all,

I bump with same problem on h8300 arches, and for solving this problem 
one and for all, I see next 2 ways:

1) export from archures.c something like 

	const bfd_arch_info_type *bfd_get_lookup_arch_head
		(enum bfd_architecture arch);

   This is not so good, because it assume hacking bfd internals.

2) Or, put gdbarch_printables_names to bfd like:

   const char **bfd_machine_printables_names (enum bfd_architecture arch);

which return all machine names for given architecture.

What do you think?

Andrey Volkov

>-----Original Message-----
>From: Alan Modra [mailto:amodra@bigpond.net.au]
>Sent: Saturday, April 20, 2002 7:26 AM
>To: Andrew Cagney
>Cc: Elena Zannoni; binutils@sources.redhat.com; gdb@sources.redhat.com
>Subject: Re: bfd/cpu-powerpc.c problems
>
>
>On Fri, Apr 19, 2002 at 02:22:40PM -0400, Andrew Cagney wrote:
>> >I wasn't aware that gdb used bfd_lookup_arch in this way, and the
>> > > description of bfd_lookup_arch says nothing about the order of
>> > > entries in the list.  I guess I can claim gdb is relying on
>> > > undocumented behaviour.
>> 
>> Well, there is nothing saying GDB can't exploit this and it 
>works for 
>> all other targets :-)
>
>I've committed the patch along with this further change.  So now the
>exploit is documented.
>
>	* archures.c (bfd_lookup_arch): Move the list order comment..
>	(struct bfd_arch_info): ..to where it belongs.
>	* bfd-in2.h: Regenerate.
>	* doc/Makfile.in: Regenerate.
>
>Index: archures.c
>===================================================================
>RCS file: /cvs/src/src/bfd/archures.c,v
>retrieving revision 1.48
>diff -u -p -r1.48 archures.c
>--- archures.c	20 Apr 2002 02:54:26 -0000	1.48
>+++ archures.c	20 Apr 2002 03:21:09 -0000
>@@ -288,7 +288,9 @@ DESCRIPTION
> .  const char *arch_name;
> .  const char *printable_name;
> .  unsigned int section_align_power;
>-.  {* True if this is the default machine for the architecture.  *}
>+.  {* True if this is the default machine for the architecture.
>+.     The default arch should be the first entry for an arch so that
>+.     all the entries for that arch can be accessed via <<next>>.  *}
> .  boolean the_default;
> .  const struct bfd_arch_info * (*compatible)
> .	PARAMS ((const struct bfd_arch_info *a,
>@@ -973,9 +975,7 @@ DESCRIPTION
> 	Look for the architecure info structure which matches the
> 	arguments @var{arch} and @var{machine}. A machine of 0 
>matches the
> 	machine/architecture structure which marks itself as the
>-	default.  gdb relies on the default arch being the first
>-	entry for the given ARCH so that all the entries for that
>-	arch can be accessed via ap->next.
>+	default.
> */
> 
> const bfd_arch_info_type *
>
>-- 
>Alan Modra
>IBM OzLabs - Linux Technology Centre
>


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