Folks,
I've just pushed a new feature out in 5.11-pre8 that will hopefully aid
in debugging future issues - the ability to dynamically (at runtime)
enable and disable debug code using the new debug.c32 module.
For instance, to turn on the dprintf() in execute(), you'd do,
debug.c32 -e execute
then, every time a module is executed you'll see messages like,
kernel is ls.c32, args = / type = 7
To disable functions,
debug.c32 -d open_file searchdir put_inode
Chances are that if you report a bug now, you'll be asked to run
debug.c32 with a list of useful debugging functions to help narrow down
the cause of your bug. The hope is that this will reduce debugging time,
especially for those difficult problems that always seem to be
environment-specific.
The majority of uses for now will be to enable dprintf() statements, but
over time expect to see more and more integrity-checking code added to
Syslinux, especially in the network stack where it makes sense to
validate input data much more aggressively for debugging purposes.
My intention is to turn this feature off for releases, but depending on
how useful it ends up being, we may keep it enabled.
--
Matt Fleming, Intel Open Source Technology Center
Op 2013-07-05 om 13:59 schreef Matt Fleming:> Folks, > > I've just pushed a new feature out in 5.11-pre8 that will hopefully aid > in debugging future issues - the ability to dynamically (at runtime) > enable and disable debug code using the new debug.c32 module. > > For instance, to turn on the dprintf() in execute(), you'd do, > > debug.c32 -e execute > > then, every time a module is executed you'll see messages like, > > kernel is ls.c32, args = / type = 7 > > To disable functions, > > debug.c32 -d open_file searchdir put_inode > > Chances are that if you report a bug now, you'll be asked to run > debug.c32 with a list of useful debugging functions to help narrow down > the cause of your bug. The hope is that this will reduce debugging time, > especially for those difficult problems that always seem to be > environment-specific. > > The majority of uses for now will be to enable dprintf() statements, but > over time expect to see more and more integrity-checking code added to > Syslinux, especially in the network stack where it makes sense to > validate input data much more aggressively for debugging purposes. > > My intention is to turn this feature off for releases, but depending on > how useful it ends up being, we may keep it enabled.Will the six point something series have this debug feature? Groeten Geert Stappers -- Leven en laten leven
On Mon, 08 Jul, at 06:26:50PM, Geert Stappers wrote:> Will the six point something series have this debug feature?Yep, it's merged in 6.02-pre1. This seems like as good a time as any to clear up any confusion about the release plan. My plans for the branches and releases (at the moment), are as follows, o merge the 'firmware' branch into 'master' o stop doing development of new features on 'elflink', and instead do it all on 'master' o see the 'elflink' branch through to a final release (5.11) and then move the 5.xx series to maintenance mode. The branches are at a point of bug-parity, where all the bugs in 5.11-pre* are also in 6.02-pre*. The constant merging between branches is proof that they have outlived their usefulness, and that we need to get back to a single development branch. Bugs will be fixed in both 'master' and 'elflink', new features only in 'master'. The merging of 'firmware' into 'master' should happen in the next two or three weeks. -- Matt Fleming, Intel Open Source Technology Center