This is the mail archive of the
mailing list for the glibc project.
Re: [gnu-csky] [PATCH v4 06/13] C-SKY: Linux ABI
On Thu, 13 Sep 2018, Arnd Bergmann wrote:
> I think the expectations are generally mismatched with reality for our
> headers. It's something that's been bugging me for a while and that
> is not trivial to fix. We've had developers in the past that tried to
> ensure that each exported uapi header can be included by itself,
> but they (I forget who last worked on that) got too frustrated over
> time to finish the job. What you found is clearly a bug on our side
> and we should try to fix it.
I note the recent proposed changes to make uapi headers build as C++ just
fudges this issue, by providing dummy definitions of all the required
types. Which can't work for my purpose, because we need the actual
definition of elf_gregset_t that the kernel uses when generating core
dumps, not a dummy unsigned long array, for tests of sizes and offsets
> Agreed. I think the main problem is that the kernel still provides certain
> types that are also provided by the C library, and other kernel headers
> have interdependencies with these.
The types in question (in both linux/elfcore.h and sys/procfs.h) are of
course types provided in both places - but in this case I'm not concerned
about being able to include both headers at once, my test includes each in
a separate file and compares the resulting sets of sizes and offsets (and
if the kernel header tried to delegate to the libc header to get the type
definitions when included from userspace code, that would defeat the point
of my test). If various types in the kernel header were to gain
__kernel_* prefixes, that would be fine for my purposes.
Joseph S. Myers