Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1314497 > unrolled thread

Re: [RFC v1 0/8] x86/init: Linux linker tables

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC v1 0/8] x86/init: Linux linker tables "H. Peter Anvin" <hpa@zytor.com> - 2016-01-21 21:30 +0100
    Re: [RFC v1 0/8] x86/init: Linux linker tables "Luis R. Rodriguez" <mcgrof@suse.com> - 2016-01-21 21:40 +0100
      Re: [RFC v1 0/8] x86/init: Linux linker tables Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> - 2016-01-21 22:40 +0100
        Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables "Luis R. Rodriguez" <mcgrof@suse.com> - 2016-01-21 23:30 +0100
          Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables "H. Peter Anvin" <hpa@zytor.com> - 2016-01-22 01:00 +0100
            Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables "Luis R. Rodriguez" <mcgrof@suse.com> - 2016-01-22 01:30 +0100
        Re: [RFC v1 0/8] x86/init: Linux linker tables Michael Brown <mcb30@ipxe.org> - 2016-01-22 09:20 +0100
    Re: [RFC v1 0/8] x86/init: Linux linker tables Michael Matz <matz@suse.de> - 2016-01-22 14:50 +0100
      Re: [RFC v1 0/8] x86/init: Linux linker tables "H. Peter Anvin" <hpa@zytor.com> - 2016-01-22 20:10 +0100
        Re: [RFC v1 0/8] x86/init: Linux linker tables "Luis R. Rodriguez" <mcgrof@do-not-panic.com> - 2016-01-22 23:00 +0100

#1314497 — Re: [RFC v1 0/8] x86/init: Linux linker tables

On 12/17/15 20:40, H. Peter Anvin wrote:
>>
>> const struct
>> foo__attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0];
>>
>> const struct
>> foo__attribute__((used,section(".rodata.tbl.tablename.999")))
>> tablename__end[0];
>>

(Over)thinking about this some more, I suggest using the empty string
for the start and "~" for the end.  And, yes, I did check that ~ works
as part of a section name.

Something that confuses me is that gcc seems to give these sections the
"aw" attributes which makes as complain.  This might be a gcc bug.
Worst case we have to use an assembly statement to create these
sections; it isn't a big deal and shouldn't make it any more
architecture-specific.

	-hpa

[toc] | [next] | [standalone]

#1314510

On Thu, Jan 21, 2016 at 12:19 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 12/17/15 20:40, H. Peter Anvin wrote:
>>>
>>> const struct
>>> foo__attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0];
>>>
>>> const struct
>>> foo__attribute__((used,section(".rodata.tbl.tablename.999")))
>>> tablename__end[0];
>>>
>
> (Over)thinking about this some more, I suggest using the empty string
> for the start and "~" for the end.  And, yes, I did check that ~ works
> as part of a section name.

Sure, do we know if that ICC compatible? Do we care? There are a
series of ICC hacks put in place on ipxe's original solution which
I've folded in, it seems that works but if we care about ICC those
folks should perhaps help review as well.

> Something that confuses me is that gcc seems to give these sections the
> "aw" attributes which makes as complain.  This might be a gcc bug.
> Worst case we have to use an assembly statement to create these
> sections; it isn't a big deal and shouldn't make it any more
> architecture-specific.

OK!

 Luis

[toc] | [prev] | [next] | [standalone]

#1314547

On Thu, Jan 21, 2016 at 12:33:43PM -0800, Luis R. Rodriguez wrote:
> On Thu, Jan 21, 2016 at 12:19 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> > On 12/17/15 20:40, H. Peter Anvin wrote:
> >>>
> >>> const struct
> >>> foo__attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0];
> >>>
> >>> const struct
> >>> foo__attribute__((used,section(".rodata.tbl.tablename.999")))
> >>> tablename__end[0];
> >>>
> >
> > (Over)thinking about this some more, I suggest using the empty string
> > for the start and "~" for the end.  And, yes, I did check that ~ works
> > as part of a section name.
> 
> Sure, do we know if that ICC compatible? Do we care? There are a
> series of ICC hacks put in place on ipxe's original solution which
> I've folded in, it seems that works but if we care about ICC those
> folks should perhaps help review as well.

I didn't know the kernel could even be compiled with ICC? Thought
only GCC worked?

Anyhow - it may be that those fixes were for quite old ICC versions.
Does the latest one manifest these oddities?

> 
> > Something that confuses me is that gcc seems to give these sections the
> > "aw" attributes which makes as complain.  This might be a gcc bug.
> > Worst case we have to use an assembly statement to create these
> > sections; it isn't a big deal and shouldn't make it any more
> > architecture-specific.
> 
> OK!
> 
>  Luis

[toc] | [prev] | [next] | [standalone]

#1314575 — Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

On Thu, Jan 21, 2016 at 1:37 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>> Sure, do we know if that ICC compatible? Do we care? There are a
>> series of ICC hacks put in place on ipxe's original solution which
>> I've folded in, it seems that works but if we care about ICC those
>> folks should perhaps help review as well.
>
> I didn't know the kernel could even be compiled with ICC? Thought
> only GCC worked?

I'm happy with that, just wanted to make sure I raise the flag concern
given the icc hacks on the linker tables.

> Anyhow - it may be that those fixes were for quite old ICC versions.
> Does the latest one manifest these oddities?

I am not sure, I yield to Michael as the author of the original ICC
compatibility pieces. If we don't care about ICC let me know and I'll
just drop the stuff. In lack of such statements I'll just keep the
work arounds in place, but I'm more than trilled to drop it.

 Luis

[toc] | [prev] | [next] | [standalone]

#1314650 — Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

On 01/21/16 14:25, Luis R. Rodriguez wrote:
> On Thu, Jan 21, 2016 at 1:37 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
>>> Sure, do we know if that ICC compatible? Do we care? There are a
>>> series of ICC hacks put in place on ipxe's original solution which
>>> I've folded in, it seems that works but if we care about ICC those
>>> folks should perhaps help review as well.
>>
>> I didn't know the kernel could even be compiled with ICC? Thought
>> only GCC worked?
> 
> I'm happy with that, just wanted to make sure I raise the flag concern
> given the icc hacks on the linker tables.
> 
>> Anyhow - it may be that those fixes were for quite old ICC versions.
>> Does the latest one manifest these oddities?
> 
> I am not sure, I yield to Michael as the author of the original ICC
> compatibility pieces. If we don't care about ICC let me know and I'll
> just drop the stuff. In lack of such statements I'll just keep the
> work arounds in place, but I'm more than trilled to drop it.
> 

In general we let the ICC and Clang/LLVM teams communicate with out a
post facto.  We can't just guess what their requirements are, especially
since they are likely to change between revisions.

	-hpa

[toc] | [prev] | [next] | [standalone]

#1314662 — Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

On Thu, Jan 21, 2016 at 03:56:35PM -0800, H. Peter Anvin wrote:
> On 01/21/16 14:25, Luis R. Rodriguez wrote:
> > On Thu, Jan 21, 2016 at 1:37 PM, Konrad Rzeszutek Wilk
> > <konrad.wilk@oracle.com> wrote:
> >>> Sure, do we know if that ICC compatible? Do we care? There are a
> >>> series of ICC hacks put in place on ipxe's original solution which
> >>> I've folded in, it seems that works but if we care about ICC those
> >>> folks should perhaps help review as well.
> >>
> >> I didn't know the kernel could even be compiled with ICC? Thought
> >> only GCC worked?
> > 
> > I'm happy with that, just wanted to make sure I raise the flag concern
> > given the icc hacks on the linker tables.
> > 
> >> Anyhow - it may be that those fixes were for quite old ICC versions.
> >> Does the latest one manifest these oddities?
> > 
> > I am not sure, I yield to Michael as the author of the original ICC
> > compatibility pieces. If we don't care about ICC let me know and I'll
> > just drop the stuff. In lack of such statements I'll just keep the
> > work arounds in place, but I'm more than trilled to drop it.
> > 
> 
> In general we let the ICC and Clang/LLVM teams communicate with out a
> post facto.  We can't just guess what their requirements are, especially
> since they are likely to change between revisions.

Great. I'm going to drop ICC hacks.

  Luis

[toc] | [prev] | [next] | [standalone]

#1314824

On 21/01/16 21:37, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 21, 2016 at 12:33:43PM -0800, Luis R. Rodriguez wrote:
>> Sure, do we know if that ICC compatible? Do we care? There are a
>> series of ICC hacks put in place on ipxe's original solution which
>> I've folded in, it seems that works but if we care about ICC those
>> folks should perhaps help review as well.
>
> I didn't know the kernel could even be compiled with ICC? Thought
> only GCC worked?
>
> Anyhow - it may be that those fixes were for quite old ICC versions.
> Does the latest one manifest these oddities?

I haven't tested building iPXE with icc for some time.  (The support for 
icc was originally added with the plan to be able to compile to EFI Byte 
Code; this plan was swiftly abandoned.)

The most recent version of icc that I have personally used with that 
code was 10.1.018.

Michael

[toc] | [prev] | [next] | [standalone]

#1314985

Hi,

On Thu, 21 Jan 2016, H. Peter Anvin wrote:

> Something that confuses me is that gcc seems to give these sections the 
> "aw" attributes which makes as complain.  This might be a gcc bug.

Workaround: use an (possibly empty) intializer:

struct foo {int i;};
const struct foo
__attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0] = {};


Ciao,
Michael.

[toc] | [prev] | [next] | [standalone]

#1315227

On 01/22/2016 05:44 AM, Michael Matz wrote:
> Hi,
> 
> On Thu, 21 Jan 2016, H. Peter Anvin wrote:
> 
>> Something that confuses me is that gcc seems to give these sections the 
>> "aw" attributes which makes as complain.  This might be a gcc bug.
> 
> Workaround: use an (possibly empty) intializer:
> 
> struct foo {int i;};
> const struct foo
> __attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0] = {};
> 

And indeed that works.  Awesome!  Much better than having to do an
assembly hack.

	-hpa

[toc] | [prev] | [next] | [standalone]

#1315315

On Fri, Jan 22, 2016 at 11:06 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 01/22/2016 05:44 AM, Michael Matz wrote:
>> Hi,
>>
>> On Thu, 21 Jan 2016, H. Peter Anvin wrote:
>>
>>> Something that confuses me is that gcc seems to give these sections the
>>> "aw" attributes which makes as complain.  This might be a gcc bug.
>>
>> Workaround: use an (possibly empty) intializer:
>>
>> struct foo {int i;};
>> const struct foo
>> __attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0] = {};
>>
>
> And indeed that works.  Awesome!  Much better than having to do an
> assembly hack.

BTW before we set these in stone given that subarch (lguest, Xen, PC)
really does provide a split in run time code we *know* we could
technically free code for subarchs not needed. I don't expect this to
happen now, but its possibility to do later seems worthy for us to
consider on architecture here on the way we define the linker tables.
As I have it linker tables are associated associated with a struct
(which hpa asked to enable anyone to peg *anything* not just structs),
these structs then have a priority which uses the linker later to sort
things for us, and it also has a subarch bitmask which tells us the
supported subarchs.

Should it be possible to resuse free_init_pages() and/or
free_reserved_area() only for routines (members in the array in this
case of a struct of fns) that don't meet our subarch once we're done
iterating over the routies and know we can discard things we know we
can drop? Through a cursory glance, *I think* its possible as-is, we
would just need easy access to the respective start and end addresses
and I guess there lies the challenge. Question is, is would that be
clean enough for us? Or are there other things you can think of that
perhaps might make this prospect cleaner later to add?

I figure better ask now for architectural purposes than later after merged.

 Luis

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web