[syslinux] EXTLINUX - GCC 5

Ady ady-sf at hotmail.com
Fri Jul 10 22:51:40 PDT 2015


> On Jul 10, 2015 5:29 PM, "poma via Syslinux" <syslinux at zytor.com> wrote:
> 
> > The same as with the ISOLINUX, stable and git.
> > Only this time has nothing to do with the menu.
> 
> 1) EXTLINUX is no longer a discrete variant.  The installer extlinux now
> installs SYSLINUX.
> 2) William Kensington already saw a similar behavior wherein an ISOLINUX
> image failed before parsing the config.
> 3) It feels like this is a moving target where gcc keeps changing and
> different results get reported.
> 4) We'll likely need to make code akin to the old tracers (on screen or
> serial) to log progress.
> 
> --Gene
 
There are at least 7 source files in Syslinux 6.03 including an 
expression similar to:
 >= ' '
and there would be many more files in the list if we were to modify or 
relax the search criteria by just one character.

Among those files (just a sample of them), there are:
 com32/elflink/ldlinux/cli.c
 com32/cmenu/libmenu/tui.c
 gnu-efi/gnu-efi-3.0/lib/console.c
 memdisk/inflate.c

and:
com32/elflink/ldlinux/readconfig.c
com32/lib/sys/argv.c
com32/rosh/rosh.c
core/dmi.c
core/fs/pxe/urlparse.c

There are, of course, more. Not all of them might be relevant to this 
gcc5 compatibility issue, but they might be candidates for review / 
improvements (or, in other words, potential source of troubles related 
to the matter in question).

If the Syslinux source code can be made more compatible with gcc v.5+, 
I think it should, specially if there are no regressions introduced by 
such potential changes.

Having said that, let's not forget that the range of inadequate 
behaviors are triggered by using gcc v. 5+, and not seen in every 
single hardware / firmware. This doesn't mean that gcc and/or the 
firmware are the problem with certainty; just that those can be / are 
the triggers (which is a positive thing, if we get to see code 
improvements).

Just as Syslinux should try to "workaround" a buggy BIOS issue whenever 
possible, and it should also "work nicely" with gcc 5+ if possible (or 
"as nicely as possible"), I think that gcc should also try to "work 
nicely" with others, and that users should check for firmware ("BIOS" / 
"UEFI") updates and report their problems to relevant manufacturers.

Sure, most of that is not in our hands, but I hope we don't expect 
"everything" from Syslinux (sometimes without even a clear feedback / 
report, just with complains and demands). Users should report to the 
hardware / firmware manufacturers, update their firmware versions, and 
(IMHO) it would be beneficial if gcc's devs try to help with some tips 
/ clues, or even some workaround parameter (considering that gcc 5+ 
seems to be triggering the issue whereas prior versions are not).

One thing that Syslinux could do is to improve debugging reports / logs 
/ methods. As examples (not necessarily related to the current 
troubleshooting issue only), output dots every X bytes during kernel's 
load / hand over, and introducing a "standardized" way for c32 files 
(plus "ldlinux.*") to include (although, not necessarily "report") the 
exact version (+ building date + commit + origin +  debug_degree_flag 
+...).

Finally, a small reminder. Since the issue is only present on specific 
hardware / firmware, whatever might seem to "solve" the behavior in one 
system might not be really a solution for others. "This/that 
works/fails for me" might be a useful report, rather than "this change 
works for me so this is the solution that Syslinux must implement right 
now for everyone". Let's be as helpful and as thorough as possible.

Regards,
Ady.
 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> 




More information about the Syslinux mailing list