This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
[RFC] RE: bfd/cpu-powerpc.c, bfd/cpu-h8300.c problems (bfd_lookup_arch)
- From: Andrew Volkov <Andrew dot Volkov at transas dot com>
- To: Alan Modra <amodra at bigpond dot net dot au>,Andrew Cagney <ac131313 at cygnus dot com>,Elena Zannoni <ezannoni at redhat dot com>
- Cc: binutils at sources dot redhat dot com, gdb at sources dot redhat dot com
- Date: Tue, 28 May 2002 17:29:40 +0400
- Subject: [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
>