This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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]

Re: [Patch mach-o/gas] make section type names target-dependent.



On 19 Dec 2011, at 12:28, Tristan Gingold wrote:



On Dec 19, 2011, at 1:20 PM, Iain Sandoe wrote:



On 19 Dec 2011, at 09:58, Tristan Gingold wrote:
On Dec 16, 2011, at 9:34 PM, Iain Sandoe wrote:

I am trying to test the four main Darwin targets as I implement things ..
.. the Idea being that, one day, we will simply be able to enable them all in configure...


Testing my current stuff (for symbol type qualifiers) reminded me that some section types are not applicable to all targets.
(At present, specifically, that means that x86-64 doesn't support symbol stubs, or {non,}lazy_symbol_stubs).


The patch below checks for a target-specific table ahead of the generic one.
I followed the current style of printing in binutils/od-macho.c and parsing in bfd/mach-o.c although I wonder if it might be more obvious to put them both back into bfd/mach-o.c and just publish the accessor routines.

Thank you for working on that.


May I suggest a slightly different approach (feel free to discuss it) ?

These section types are defined independently of the targets. So I think they must stay in bfd_mach_o_section_type_name.
I agree that some are not valid on some targets. So just add a subtarget hook that returns FALSE if the section type is not supported by
the target.

Seems reasonable - I suppose we can work on the principle that the section type can't be in an object unless it's supported - so we only need to check when creating/writing.


new version,
OK?

Almost OK for me. I don't understand the reordering of bfd_mach_o_section type. They were ordering by values. What is the new criteria ?

Well, the expensive search is on the text when running gas. I was thinking that, ideally, the tables would be ordered so that the most- often-used types are near the beginning (a dup value had also crept in).


OK without these reordering chunks.

presumably it's OK to remove the dup - or have I missed something?


Should I commit ?

I suppose I should do this one.. and see if I have everything in place correctly...


cheers
Iain


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