Issue with v2.25 on OS/2

Issue with v2.25 on OS/2

[Paul Smedley]

Hi All,

I've been maintaining a port of binutils to the OS/2 platform for some years.

I updated my local source to v2.25 yesterday, and an issue with ar has 
cropped up.

Previous versions of binutils had a symbol header of __.SYMDEF - with v2.25 I 
get a / instead

Reading the source I see that:
 Symbol table (must be first):
 "__.SYMDEF       " - Symbol table, Berkeley style, produced by ranlib.
 "/               " - Symbol table, system 5 style.


So for some reason, the OS/2 build has changed to use system 5 style instead 
of the required Berkeley style.

Can anyone help me understand where it is defined which kind of symbol table 
is used for a given platform?

OS/2 uses aout object format fwiw.

Cheers,

Paul

Re: Issue with v2.25 on OS/2

[Tristan Gingold]

> On 06 Jan 2015, at 09:54, Paul Smedley <paul@smedley.id.au> wrote:
> 
> Hi All,
> 
> I've been maintaining a port of binutils to the OS/2 platform for some years.
> 
> I updated my local source to v2.25 yesterday, and an issue with ar has 
> cropped up.
> 
> Previous versions of binutils had a symbol header of __.SYMDEF - with v2.25 I 
> get a / instead
> 
> Reading the source I see that:
> Symbol table (must be first):
> "__.SYMDEF       " - Symbol table, Berkeley style, produced by ranlib.
> "/               " - Symbol table, system 5 style.
> 
> 
> So for some reason, the OS/2 build has changed to use system 5 style instead 
> of the required Berkeley style.
> 
> Can anyone help me understand where it is defined which kind of symbol table 
> is used for a given platform?
> 
> OS/2 uses aout object format fwiw.

What is your host ?  Have you enabled plugins ?

Re: Issue with v2.25 on OS/2

[Paul Smedley]

Hi Tristan,

Tristan Gingold <gingold <at> adacore.com> writes:
> > On 06 Jan 2015, at 09:54, Paul Smedley <paul <at> smedley.id.au> wrote:
> > Can anyone help me understand where it is defined which kind of symbol 
table 
> > is used for a given platform?
> > 
> > OS/2 uses aout object format fwiw.
> 
> What is your host ?  Have you enabled plugins ?
Host is os2-emx - I have a set of diffs here to enable it. I have not 
enabled plugins, and never have done previously.

Cheers,

Paul

Re: Issue with v2.25 on OS/2

[Tristan Gingold]

> On 06 Jan 2015, at 10:23, Paul Smedley <paul@smedley.id.au> wrote:
> 
> Hi Tristan,
> 
> Tristan Gingold <gingold <at> adacore.com> writes:
>>> On 06 Jan 2015, at 09:54, Paul Smedley <paul <at> smedley.id.au> wrote:
>>> Can anyone help me understand where it is defined which kind of symbol 
> table 
>>> is used for a given platform?
>>> 
>>> OS/2 uses aout object format fwiw.
>> 
>> What is your host ?  Have you enabled plugins ?
> Host is os2-emx - I have a set of diffs here to enable it. I have not 
> enabled plugins, and never have done previously.


Ok.  Check the set of BFD_JUMP_TABLE_ARCHIVE entries in your bfd_target.
Debugging shouldn't be very difficult, set a breakpoint on archives.c:
_bfd_compute_and_write_armap, and see which write_armap is called.

Regards,
Tristan.

Re: Issue with v2.25 on OS/2

[Paul Smedley]

Hi Tristan,

Tristan Gingold <gingold <at> adacore.com> writes:

> Ok.  Check the set of BFD_JUMP_TABLE_ARCHIVE entries in your bfd_target.
> Debugging shouldn't be very difficult, set a breakpoint on archives.c:
> _bfd_compute_and_write_armap, and see which write_armap is called.

coff_write_armap is being called - which I guess explains the wrong header.

BFD_JUMP_TABLE_ARCHIVE is being set from aout-target.h

Cheers,

Paul

Re: Issue with v2.25 on OS/2

[Paul Smedley]

Hi again,

Paul Smedley <paul <at> smedley.id.au> writes:

> Tristan Gingold <gingold <at> adacore.com> writes:
> 
> > Ok.  Check the set of BFD_JUMP_TABLE_ARCHIVE entries in your bfd_target.
> > Debugging shouldn't be very difficult, set a breakpoint on archives.c:
> > _bfd_compute_and_write_armap, and see which write_armap is called.
> 
> coff_write_armap is being called - which I guess explains the wrong header.
> 
> BFD_JUMP_TABLE_ARCHIVE is being set from aout-target.h

I modified aout-target.h to force BFD_JUMP_TABLE_ARCHIVE to 
BFD_JUMP_TABLE_ARCHIVE(_bfd_archive_bsd) for OS/2, unfortunately it didn't 
help :(

Re: Issue with v2.25 on OS/2

[Tristan Gingold]

> On 07 Jan 2015, at 08:25, Paul Smedley <paul@smedley.id.au> wrote:
> 
> Hi again,
> 
> Paul Smedley <paul <at> smedley.id.au> writes:
> 
>> Tristan Gingold <gingold <at> adacore.com> writes:
>> 
>>> Ok.  Check the set of BFD_JUMP_TABLE_ARCHIVE entries in your bfd_target.
>>> Debugging shouldn't be very difficult, set a breakpoint on archives.c:
>>> _bfd_compute_and_write_armap, and see which write_armap is called.
>> 
>> coff_write_armap is being called - which I guess explains the wrong header.
>> 
>> BFD_JUMP_TABLE_ARCHIVE is being set from aout-target.h
> 
> I modified aout-target.h to force BFD_JUMP_TABLE_ARCHIVE to 
> BFD_JUMP_TABLE_ARCHIVE(_bfd_archive_bsd) for OS/2, unfortunately it didn't 
> help :(

Then set a breakpoint in coff_write_armap to understand why it is called.
Maybe the bfd_target is not the one you expect.

Re: Issue with v2.25 on OS/2

[Paul Smedley]

Hi Tristan,

Tristan Gingold <gingold <at> adacore.com> writes:
> > On 07 Jan 2015, at 08:25, Paul Smedley <paul <at> smedley.id.au> wrote:
> > Paul Smedley <paul <at> smedley.id.au> writes:
> >> Tristan Gingold <gingold <at> adacore.com> writes:
> >>> Ok.  Check the set of BFD_JUMP_TABLE_ARCHIVE entries in your 
bfd_target.
> >>> Debugging shouldn't be very difficult, set a breakpoint on 
archives.c:
> >>> _bfd_compute_and_write_armap, and see which write_armap is called.
> >> 
> >> coff_write_armap is being called - which I guess explains the wrong 
header.
> >> 
> >> BFD_JUMP_TABLE_ARCHIVE is being set from aout-target.h
> > 
> > I modified aout-target.h to force BFD_JUMP_TABLE_ARCHIVE to 
> > BFD_JUMP_TABLE_ARCHIVE(_bfd_archive_bsd) for OS/2, unfortunately it 
didn't 
> > help :(
> 
> Then set a breakpoint in coff_write_armap to understand why it is called.
> Maybe the bfd_target is not the one you expect.

OK thanks for the tip.

Turns out I was wrong when I answered your earlier question regarding 
plugin support. Looking with the debugger mentioned 'plugin' and unknown 
variant.

I went looking and found:
#define BFD_SUPPORTS_PLUGINS 1

If I run configure in the bfd directory explicitly with --disable-plugins 
and rebuild ar - then it works :)

Thanks for the tips - now to figure out how to default plugin support to 
off :)

Cheers,

Paul