Re: [Xen-devel] [PATCH v3] ns16550-Add-command-line-parsing-adjustments

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.04.17 at 17:51, <sparatey@xxxxxxx> wrote:
> I have a question about __initconst that you mentioned.

Sure, but please trim your replies.

> On 4/3/2017 6:55 AM, Jan Beulich wrote:
>>>>> On 31.03.17 at 17:42, <swapnil.paratey@xxxxxxx> wrote:
>>> +/* enum struct keeping a table of all accepted parameter names
>>> + * for parsing cmdline for serial port com1 and com2 */
>>> +static struct serial_param_var sp_vars[] = {
>> const ... __initconst plus you should aim at arranging for the
>> string literals below to also get placed in .init.rodata (instead of
>> .rodata).
> 
> Adding an __initconst before the variable name (or after it) makes
> sp_vars go into the .init.data section if I check through
> "objdump -t xen-syms | grep sp_vars"
> 
> I'm not being able to see an init.rodata section at all for any
> other variable to emulate similar behavior i.e.
> doing an "objdump -t xen-syms | grep .init.rodata"
> doesn't show any results (whereas .init.data shows many).
> 
> The header file for __initconst defines it as .init.rodata but
> sp_vars ends up in init.data
> 
> I compile Xen by going into xen/xen and running make -j`nproc`
> 
> Please let me know if I'm misunderstanding something.
> What behavior I should expect and what is expected for adding
> these string literals. Pointing to an example would be helpful.

See the linker script: .init.rodata (and a few sub-flavors) get
merged into .init.data. We don't _currently_ have a need to
separate r/o from r/w init data, but source code should
nevertheless correctly reflect const-ness. Hence you looking
at xen-syms instead of ns16550.o is misleading you.

As to examples - please simply grep for other uses of __initconst.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel