This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: qnx-nto elf backend
- From: <gp at qnx dot com>
- To: "Nick Clifton" <nickc at redhat dot com>, "Graeme Peterson" <gp at qnx dot com>
- Cc: <binutils at sources dot redhat dot com>
- Date: Wed, 31 Jul 2002 11:54:22 -0000
- Subject: Re: qnx-nto elf backend
Thanks, Nick.
This change along with ppc-nto support will be in a patch
submission later today. Oh, without .in's but with ChangeLogs.
:-)
Regards,
GP
Nick Clifton <nickc@redhat.com> said:
> Hi Graeme,
>
> > The elf bfd backend functions I added for i386qnx need to be
> > farmed out and made available for all qnx nto targets.
> >
> > I have declared three functions, a macro, and defined the
> > following in elf32-i386qnx.c:
> >
> > #define elf_backend_set_nonloadable_filepos
elf_i386qnx_set_nonloadable_filepos
> > #define elf_backend_is_contained_by_filepos
elf_i386qnx_is_contained_by_filepos
> > #define elf_backend_copy_private_bfd_data_p
elf_i386qnx_copy_private_bfd_data_p
> >
> > What I want is to put them in a common file, rename them from
> > "elf_i386qnx_*" to "elf_qnx*", and then include that common
> > file in elf32-i386qnx.c and elfarmqnx-nabi.c, and define the
> > functions as:
> >
> > #define elf_backend_set_nonloadable_filepos
elf_qnx_set_nonloadable_filepos
> > #define elf_backend_is_contained_by_filepos
elf_qnx_is_contained_by_filepos
> > #define elf_backend_copy_private_bfd_data_p
elf_qnx_copy_private_bfd_data_p
> >
> > Questions:
> > ==========
> >
> > - Should I make the definitions in the common file, or in each of the
> > elf_*qnx*.c files? I tend toward the latter, in case there is any
> > divergence in the future.
>
> I would suggest that you put them in the common file, but protect them
> with #ifndef's:
>
> #ifndef elf_backend_set_nonloadable_filepos
> #define elf_backend_set_nonloadable_filepos
elf_qnx_set_nonloadable_filepos
> #endif
> ...etc...
>
> That way you can just #include the common file for now, which is less
> work, and if, in the future, you need to override them for particular
> targets you can do so.
>
>
> > - Should the common file be a C file or a header file? I tend towards
> > a C file for debugging reasons.
>
> It should not matter to a debugger whether the file is a .h or a .c
> file. The prevailing trend in the BFD sources though is to use a .h
> file for this kind of thing. But this is not a hard and fast rule and
> if you would prefer to use a .c file then go ahead.
>
> Cheers
> Nick
>
>
>
>
--