Re: [PATCH] NetBSD/i386 port

[Marco Gerards]

"Lubomir Kundrak" <address@hidden> writes:


Hi Lubomir,

> I've made some effort to port GNU GRUB to NetBSD/i386, possibly making it
> more system independent and portable.

Nice!  thanks a lot for doing this.

> Most of my work is a couple of small bugfixes, but there are some bigger
> issues that have to be dealt with and undoubtly need some more work and
> discussion. Anyways, with my patches whole grub builds, but since I didn't
> do any extensive testing I can't tell whether it behaves correctly.

Have you at least tried grub-emu or so?

> My environment is: NetBSD/i386 3.99.9 (gcc 3.3.3)
>
> Well, here is summary of issues:
> ================================
>
> 1.) Non-executable stack mappings.
> ----------------------------------
>
> Files affected: kern/mm.c, normal/misc.c
>
> This is probably more a gcc issue (my is gcc version 3.3.3 (NetBSD nb3
> 20040520)). As of 2.0, NetBSD/i386 uses non-executable mapping of stack
> and thus when nested functions are used it generates call to
> __enable_execute_stack() (which is actually in libgcc) even if -nostdlib
> is used. Since I know no way to disable this behavior (but there might be
> some) only workaround known to me is providing dumb __enable_execute_stack()
> functions where apropriate.

When is this required?  When using grub-emu or any other userland
utility?  In that case GRUB is linked to the C library.

In the case it is used for GRUB itself, it is useless.  GRUB executes
within its own environment.  So in that case we should just make sure
this doesn't show up.  Perhaps by using different compiler flags.

> Anyways, kern/mm.c and normal/misc.c are really not the best places
> for such a hack to take place.

Agreed.

> 2.) memalign()
> --------------
>
> Files affected: util/misc.c configure.ac Makefile.in conf/i386-pc.rmk
>
> The missing memalign() issue is was already discussed some time ago, and
> mr. Okuji also provided some solution here:
> http://lists.gnu.org/archive/html/grub-devel/2004-03/msg00048.html
> http://lists.gnu.org/archive/html/grub-devel/2004-03/msg00053.html
>
> I don't know about other systems, but NetBSD base installation contains
> GNU malloc library, which provides memalign(). Unlike some other commercial
> UNIX environments Microsoft SFU's Interix has no memalign()
> implementation, but
> I think there is no need and probably no way to support this plattform.

If the GNU malloc library helps here and it is available for FreeBSD
and OpenBSD this seems like the best solution to me.  IIRC one of
these two systems didn't have memalign.

> 3.) argp
> --------
>
> Files affected: util/grub-emu.c, configure.ac, Makefile.in, conf/i386-pc.rmk
>
> Argp framework is also GNU libc specific. For it is not present in other
> libcs we might have to exclude grub-emu from nonGNU builds, replace argp
> with getopt, or provide argp routines. As excluding grub-emu is undoubtly
> unacceptable and there was certainly some reason why argp was used, glibc's
> argp needs some replacement.

As GRUB, just like glibc is a GNU package this is a good choice.
Besides that, I wonder if BSD supports getopt_long.

> The same problem rose in effort to make LSH portable. LSH authors decided
> to include argp code in their distribution. Their version is a hacked glibc
> splitout that is not even dependent on getopt. Fortunatelly, they provide
> and maintain the agrp code also separately from LSH.
>
> LSH and their way to handle argp dependency:
> http://www.lysator.liu.se/~nisse/lsh/
> http://cvs.lysator.liu.se/viewcvs/viewcvs.cgi/lsh/src/argp/?root=lsh
>
> Argp-standalone:
> http://www.lysator.liu.se/~nisse/misc/
> http://lists.gnu.org/archive/html/bug-gnulib/2003-03/msg00002.html
> http://www.freshports.org/devel/argp-standalone/
>
> The way that seems most wise to me is not to incude argp code, but make
> GRUB on nonGNU platforms dependent on arpg-standalone. Assuming that
> package systems (such as Free|OpenBSD ports and pkgsrc) will be primary way
> to install GRUB, we will need argp-standalone package to appear in them.
> There already exists FreeBSD package for it and I may write pkgsrc package
> (for NetBSD and DragonFly).

If it can be solved this way, that would be great.  Another option is
including argp from GNU lib.  But not including external sourcecode
seems like the better option, because we don't have to keep things
up-to-date.

> And small bugfixes:
> ===================
>
> 1.) BUILD_ options handling
> ---------------------------
>
> Files affected: configure.ac, Makefile.in
>
> I found no better way to specify build flags than passsing BUILD_*
> options. This is what my configure line looks like:
> (i have liblzo in /usr/pkg and argp-standalone in /usr/local)
>
> ./configure \
>         BUILD_LDFLAGS='-L/usr/pkg/lib -L/usr/local/lib'                   
>             \
>         BUILD_CPPFLAGS='-I/usr/pkg/include -I/usr/local/include -Wall -W' 
>       \
>         BUILD_CFLAGS='-g'
>
> Another issue is that -O2 doesn't work correctly for me.
> In util/i386/pc/getroot.c:find_root_device() dev variable is stored
> in ebx register (when level 2 optimalizations used) and this register is
> modified by call to lstat(). And call  to lstat() also clobbers ent
> structure ... I haven&#8217;t investigated that yet. This is likely not a
> GRUB bug,
> but to work it around I had to override BUILD_CFLAGS ommiting -O2.

I agree that overriding LDFLAGS and CPPFLAGS is quite useful.  The
problem with using random other flags like optimizations might
seriously disrupt GRUB.

I don't know a good way to fix this problem.

> 2.) GNU bison dependency
> ------------------------
>
> Files affected: configure.ac, Makefile.in
>
> Set $(YACC) to bison if bison is found.
> This is currently mandatory on platforms where 'yacc' binary is not bison,
> because only bison works. Should this be changed (corrected?).

If bison isn't used the code most likely doesn't work.  The best fix
would just be showing an error when it was not found.  Relying on
something other than bison doesn't seem the best solution to me.  I
want to use bison specific features and I don't want to provide
workarounds for other yacc implementations.

> 3.) bindir's not sbindir
> ------------------------
>
> Files affected: util/i386/pc/grub-install.in

Can you explain this in more detail?

> 4.) GNU uniq
> ------------
>
> Files affected: geninit.sh
>
> Still haven't found out what uniq's -W1 and -t':' parameters do.
> Found them in some manuals (ok, didn't read them :) and in some no.
> Are they still part of current coreutils? And if yes, they are certainly
> not standard and should be replaced by something else.
>
> My opinion about using utils like uniq is that only SUSv2 or POSIX or
> ...I mean that only standard and portable switches should be used.

Personally I don't care much about using non-GNU utilities in the
build process.  I expect the people who actually build GRUB 2
themselves can install the required builddeps.  It's not really that
strange when GNU programs rely on other GNU programs in their build
process.

It's weird that you don't have the -t option, I thought it was POSIX.
It means that `:' is used as separator instead of ` '.  The argument
`-W1' means that it only compares once per line.

Can you provide something which does the same and doesn't break the
build process for other ports?  Or can you install coreutils?

> Index: Makefile.in
> ===================================================================
> RCS file: /usr/home/lkundrak/cvs/grub/grub/Makefile.in,v
> retrieving revision 1.16
> retrieving revision 1.16.2.5
> diff -u -r1.16 -r1.16.2.5
> --- Makefile.in        18 Nov 2005 14:56:55 -0000        1.16
> +++ Makefile.in        30 Nov 2005 08:46:24 -0000        1.16.2.5
> @@ -57,17 +57,23 @@
>  CC = @CC@
>  CFLAGS = @CFLAGS@
>  CPPFLAGS = -I. -Iinclude -I$(srcdir)/include -Wall -W
> +
>  BUILD_CC = @BUILD_CC@
> -BUILD_CFLAGS = -g -O2
> -BUILD_CPPFLAGS = -I. -Iinclude -I$(srcdir)/include -Wall -W \
> -        -DGRUB_DATADIR=\"$(pkgdatadir)\"
> +BUILD_CFLAGS = @BUILD_CFLAGS@
> +BUILD_CPPFLAGS = @BUILD_CPPFLAGS@
> +BUILD_CPPFLAGS += -I. -Iinclude -I$(srcdir)/include
> -DGRUB_DATADIR=\"$(pkgdatadir)\"
> +BUILD_LDFLAGS = @BUILD_LDFLAGS@

I am not yet sure if this really is the right thing to do.  It fixes
things for you, but I am more interested in if other things horribly
break.

> Index: conf/i386-pc.rmk
> ===================================================================

[...]

I suppose you can't test this on the PPC? :-)

Thanks,
Marco