What size-dependent parts of bfd/elfcode.h are undesirable?

What size-dependent parts of bfd/elfcode.h are undesirable?

[Jozef Lawrynowicz]

There is a comment at the top of bfd/elfcode.h:

> (2)  The code in this file is compiled twice, once in 32-bit mode and
>       once in 64-bit mode.  More of it should be made size-independent
>       and moved into elf.c.
>

If I am adding a new ELF type which has 32 and 64-bit versions and has similar
requirements to relocation entries, is it ok to copy much of the implementation
required to support Elf_External_Rel for my new type? i.e. swap_{in,out}
functions, size-independent mappings of external types
(Elf_External_Rel -> Elf{32,64_External_Rel}) and field accessors
(ELF_R_INFO -> Elf{32,64}_R_INFO).

Is there a new recommended way to do something like this, or is the comment
referring to some other parts of the size-dependent implementation?

Thanks,
Jozef

Re: What size-dependent parts of bfd/elfcode.h are undesirable?

[H.J. Lu]

On Thu, Apr 9, 2020 at 11:28 AM Jozef Lawrynowicz
<jozef.l@mittosystems.com> wrote:
>
> There is a comment at the top of bfd/elfcode.h:
>
> > (2)  The code in this file is compiled twice, once in 32-bit mode and
> >       once in 64-bit mode.  More of it should be made size-independent
> >       and moved into elf.c.
> >
>
> If I am adding a new ELF type which has 32 and 64-bit versions and has similar
> requirements to relocation entries, is it ok to copy much of the implementation
> required to support Elf_External_Rel for my new type? i.e. swap_{in,out}
> functions, size-independent mappings of external types
> (Elf_External_Rel -> Elf{32,64_External_Rel}) and field accessors
> (ELF_R_INFO -> Elf{32,64}_R_INFO).
>
> Is there a new recommended way to do something like this, or is the comment
> referring to some other parts of the size-dependent implementation?
>
> Thanks,
> Jozef

Please take a look at elf_append_rel and elf_append_rela.  The same
function is used for both 32bit and 64bit ELF.


-- 
H.J.

Re: What size-dependent parts of bfd/elfcode.h are undesirable?

[Jozef Lawrynowicz]

On Thu, 9 Apr 2020 11:56:56 -0700
"H.J. Lu" <hjl.tools@gmail.com> wrote:

> On Thu, Apr 9, 2020 at 11:28 AM Jozef Lawrynowicz
> <jozef.l@mittosystems.com> wrote:
> >
> > There is a comment at the top of bfd/elfcode.h:
> >  
> > > (2)  The code in this file is compiled twice, once in 32-bit mode and
> > >       once in 64-bit mode.  More of it should be made size-independent
> > >       and moved into elf.c.
> > >  
> >
> > If I am adding a new ELF type which has 32 and 64-bit versions and has similar
> > requirements to relocation entries, is it ok to copy much of the implementation
> > required to support Elf_External_Rel for my new type? i.e. swap_{in,out}
> > functions, size-independent mappings of external types
> > (Elf_External_Rel -> Elf{32,64_External_Rel}) and field accessors
> > (ELF_R_INFO -> Elf{32,64}_R_INFO).
> >
> > Is there a new recommended way to do something like this, or is the comment
> > referring to some other parts of the size-dependent implementation?
> >
> > Thanks,
> > Jozef  
> 
> Please take a look at elf_append_rel and elf_append_rela.  The same
> function is used for both 32bit and 64bit ELF.
> 
> 

But they both rely on the size-dependent functions from elfcode.h to actually
do the work.

What I meant for my original question is that if I'm implementing a similar type
to Elf{32,64}_Rel from scratch, should I just follow the template for these
types or should I strive to do it in some size-independent way that is
self-contained within elf.c? For example by having conditional statements that
check the EI_CLASS of field of the ELF header to determine whether to output
data for a 32-bit or 64-bit target.

Perhaps I read too much into that comment at the top of elfcode.h, and
should just go with the current method used in this file, relying on the fact
it will be compiled separately for 32-bit and 64-bit targets. That seems a lot
neater than having loads of checks for EI_CLASS in elf.c.

Thanks,
Jozef