search for: section_typ

...additional pieces, namely "ax" and >> @progbits. > > Extend the section attribute to allow additional parameters? > > Joerg > The idea would be to create additional function attributes. I have not spent time thinking this through yet. section_flags("flags") section_type("type") others.... so then void x(int i) __attributes__((section("mysection"), section_flags("aw"), section_type("@progbits")) ; or maybe extend the syntax of section section(<name> [<section_flags>] [,<type>])

On Fri, Apr 19, 2013 at 09:47:28AM -0700, reed kotler wrote: > The clean solution is probably to add two additional function > attributes to cover these additional pieces, namely "ax" and > @progbits. Extend the section attribute to allow additional parameters? Joerg

> The idea would be to create additional function attributes. > I have not spent time thinking this through yet. > > section_flags("flags") > section_type("type") > others.... What would the semantic be of having section_flags but no section name? > so then > > void x(int i) __attributes__((section("mysection"), section_flags("aw"), > section_type("@progbits")) ; > > or maybe extend the...

...@progbits. >> >> >> Extend the section attribute to allow additional parameters? >> >> Joerg >> > The idea would be to create additional function attributes. > I have not spent time thinking this through yet. > > section_flags("flags") > section_type("type") > others.... > This sounds awful. > so then > > void x(int i) __attributes__((section("mysection"), section_flags("aw"), > section_type("@progbits")) ; > > or maybe extend the syntax of section > > section(<name>...

...om /etc/glusterfs/glusterfs-client.vol 2008-10-31 12:30:17 D [spec.y:107:new_section] parser: New node for 'sirius00' 2008-10-31 12:30:17 D [xlator.c:115:xlator_set_type] xlator: attempt to load file /usr/local/lib/glusterfs/1.3.12/xlator/protocol/client.so 2008-10-31 12:30:17 D [spec.y:127:section_type] parser: Type:sirius00:protocol/client 2008-10-31 12:30:17 D [spec.y:141:section_option] parser: Option:sirius00:transport-type:tcp/client 2008-10-31 12:30:17 D [spec.y:141:section_option] parser: Option:sirius00:remote-host:10.3.10.200 2008-10-31 12:30:17 D [spec.y:141:section_option] parser: Opt...

On 2020-11-17, Igor Kudrin wrote: > >On 17.11.2020 14:05, Fāng-ruì Sòng wrote: >>On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote: >>> >>>On 14.11.2020 3:42, Fāng-ruì Sòng wrote: >>>>For .debug_* in object files: >>>> >>>>DWARF32 -> SHT_PROGBITS (unchanged) >>>>DWARF64 ->

...spec from /etc/glusterfs/glusterfs-afr1.vol 2008-12-09 14:52:55 D [spec.y:107:new_section] parser: New node for 'client1' 2008-12-09 14:52:55 D [xlator.c:115:xlator_set_type] xlator: attempt to load file /usr/lib/glusterfs/1.3.12/xlator/protocol/client.so 2008-12-09 14:52:55 D [spec.y:127:section_type] parser: Type:client1:protocol/client 2008-12-09 14:52:55 D [spec.y:141:section_option] parser: Option:client1:transport-type:tcp/client 2008-12-09 14:52:55 D [spec.y:141:section_option] parser: Option:client1:remote-host:192.168.1.176 2008-12-09 14:52:55 D [spec.y:141:section_option] parser:...

...ly on this information. This sems somewhat of a heavy handed approach to solving this problem. Alternatively, if we do want to go with something more official then just doing it in a linker using first reloc, why not use sh_info? Seems like it's made for providing an extra information for each section_type. In this case .debug_*. With it we have a current behavior of using names which as far as I can tell the default for figuring out debug sections. If producer provides this extra information the linker can improve layout to help with debug sections overflows, if producer doesn't provide this i...

...documentation is here: > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472m/chr1359124985290.html > > We do not aim for or anticipate syntax-level compatibility; merely the > ability to do something similar in Clang. In particular Clang can't support > the "section_type" specifier without significant rewrite, as LLVM decides > the section type (NOBITS/PROGBITS) by textual matching on the section name > (gross, but the fix is well beyond our scope). > > Given that documentation, you can also see why the Microsoft compatibility > option *almost*...

.../glusterfs/glusterfs-client.vol > 2008-08-24 18:20:33 D [spec.y:107:new_section] parser: New node for 'client' > 2008-08-24 18:20:33 D [xlator.c:115:xlator_set_type] xlator: attempt to load file /usr/lib/glusterfs/1.3.11/xlator/protocol/client.so > 2008-08-24 18:20:33 D [spec.y:127:section_type] parser: Type:client:protocol/client > 2008-08-24 18:20:33 D [spec.y:141:section_option] parser: Option:client:transport-type:tcp/client > 2008-08-24 18:20:33 D [spec.y:141:section_option] parser: Option:client:remote-host:10.0.0.254 > 2008-08-24 18:20:33 D [spec.y:141:section_option] par...

...* of the record header */ + __u32 section_length; + __u16 revision; /* must be CPER_RECORD_REV */ + __u8 validation_bits; + __u8 reserved; /* must be zero */ + __u32 flags; + uuid_le section_type; + uuid_le fru_id; + __u32 section_severity; + __u8 fru_text[20]; +}; + +/* Reset to default packing */ +#pragma pack() + +#endif diff -r b622e411eef8 xen/include/xen/spinlock.h --- a/xen/include/xen/spinlock.h Thu Jun 24 21:56:03 2010 +0100 +++ b/xen/include/xen/spin...