This is the mail archive of the
mailing list for the binutils project.
Re: [patches] Re: [PATCH 1/2] RISC-V: Support ELF attribute for gas and readelf
- From: Kito Cheng <kito dot cheng at gmail dot com>
- To: patches at groups dot riscv dot org, Jim Wilson <jimw at sifive dot com>
- Cc: binutils at sourceware dot org, Palmer Dabbelt <palmer at sifive dot com>
- Date: Fri, 21 Dec 2018 14:08:42 +0800
- Subject: Re: [patches] Re: [PATCH 1/2] RISC-V: Support ELF attribute for gas and readelf
- References: <CA+yXCZCDx7bk0r92SC27XUDNvfd9Yg6PQMxeOA0Ksx_qU=nrfA@mail.gmail.com> <CAFyWVaa88VuGnst1-ne8xfG6MUazF0qEZ_k_OQwtnoqqU18e2w@mail.gmail.com>
Thanks you review :)
> ... because there is
> no way to find the next attribute if you don't know if new unrecognized
> attributes tag have a string or int argument. So the even/odd rule gives us
> better forward compatibility.
I agree your point, I'll update spec PR later to follow even/odd rule.
> It isn't clear why priv_spec, priv_spec_minor, priv_spec_revision,
> unsigned_access, and stack_align are marked as NO_DEFAULT. It looks like
> only ARM uses NO_DEFAULT, and it only uses it for one Tag, Tag_nodefaults.
> The ARM ABI docs say that if Tag_nodefaults appears, then all following tags
> in the same scope are undefined if the arg is missing. Though the
> implementation doesn't seem to do that, so maybe I'm reading it wrong, or it
> wasn't implemented right for ARM. Anyways, if this works the way ARM
> documented it, then you are using it wrong. I think it should be left out.
> This simplifies riscv_elf_obj_attrs_arg_type even more, and maybe lets you
> eliminate it with some tag renumbering.
I've discussed with our guy, why we mark NO_DEFAULT, it's because the
default behavior of attribute will treat 0 as a default value, that's
mean it will not emit out attribute even we explicit write
`.attribute priv_spec, 0` in file,
that's the reason we change the name/meaning of strict_align to
unsigned_access in latest PR.
Whatever, I think it could remove, and it seems wired and not well defined for