search for: create_args_and_load

...hain.c32 receives no parameters. Similarly, using -iso- memdisk initrd=/myimage.ima displays a memdisk error saying no No ramdisk image specified! As an awkward test to confirm the problem lies somewhere behind syslinux_run_command, I replaced whichsys.c's call to syslinux_run_command(str) with create_args_and_load(str). In this situation, the whichsys chain.c32 example works without issue. (Of course, create_args_and_load only supports com32 modules, so much of whichsys's load functionality is lost. Not a good solution :). Any ideas why parameters are being lost with syslinux_run_command? --Ian

...hen I try to debug the kontron_wdt.c32 I can see that syslinux_run_command(..) returns -1. What could cause this? I've tried the ifcpu.c32 application as well (which is a bit similar to kontron_wdt.c32) and it also cannot call syslinux_run_command(). I can see that syslinux_run_command() call create_args_and_load() but if I put any printf's there they're not printed to screen, so it's pretty hard to debug what's causing the error. If someone knows a way to call two labels that would also work as a workaround for the problem I'm trying to solve. -- Bjoern

...eceives no parameters. Similarly, using -iso- memdisk initrd=/myimage.ima displays a memdisk error saying no No ramdisk image specified! > > As an awkward test to confirm the problem lies somewhere behind syslinux_run_command, I replaced whichsys.c's call to syslinux_run_command(str) with create_args_and_load(str). In this situation, the whichsys chain.c32 example works without issue. (Of course, create_args_and_load only supports com32 modules, so much of whichsys's load functionality is lost. Not a good solution :). > > > > Any ideas why parameters are being lost with syslinux_run_com...

...c32 receives no parameters. Similarly, using -iso- memdisk initrd=/myimage.ima displays a memdisk error saying no No ramdisk image specified! > As an awkward test to confirm the problem lies somewhere behind syslinux_run_command, I replaced whichsys.c's call to syslinux_run_command(str) with create_args_and_load(str). In this situation, the whichsys chain.c32 example works without issue. (Of course, create_args_and_load only supports com32 modules, so much of whichsys's load functionality is lost. Not a good solution :). > > Any ideas why parameters are being lost with syslinux_run_command? >...

...es no parameters. Similarly, using -iso- memdisk initrd=/myimage.ima displays a memdisk error saying no No ramdisk image specified! > > > As an awkward test to confirm the problem lies somewhere behind syslinux_run_command, I replaced whichsys.c's call to syslinux_run_command(str) with create_args_and_load(str). In this situation, the whichsys chain.c32 example works without issue. (Of course, create_args_and_load only supports com32 modules, so much of whichsys's load functionality is lost. Not a good solution :). > > > > > > Any ideas why parameters are being lost with syslin...

...?p=syslinux/syslinux.git;a=commit;h=975a4c3b343c09a340d95f1a2a4ece3556c57a10 > And syslinux_run_command() in 2007: > http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=0b3b862ff49ab1b0b5d5af8c15d58e3c4baaf634 > > At this point, syslinux_run_command is using the equivalent of > create_args_and_load(), a function that is *not* negatively affected > by ALLOWOPTIONS. > > The behavior was changed in 2013 to use load_kernel to *add* label support: > http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=04f40bc55ed4f39d6c625b017bb16907f7d50c05 > > At this point the 8 or 9 com...

> I didn't see any further communication here; would anyone be > against my submitting/proposing a patch for this? Contributions are always welcome. > > I can see two possible approaches. One approach would be to > isolate the restriction on user commands away from > syslinux_run_command / load_kernel. > > Another would perhaps be to add support for a

...nux/execute.c b/com32/elflink/ldlinux/execute.c index 653c880..3955571 100644 --- a/com32/elflink/ldlinux/execute.c +++ b/com32/elflink/ldlinux/execute.c @@ -44,6 +44,7 @@ const struct image_types image_boot_types[] = { { NULL, 0 }, }; +extern jmp_buf __return_to_command_prompt; extern int create_args_and_load(char *); __export void execute(const char *cmdline, uint32_t type, bool sysappend) @@ -136,7 +137,8 @@ __export void execute(const char *cmdline, uint32_t type, bool sysappend) /* Restore the console */ ldlinux_console_init(); - ldlinux_enter_command(); + /* Jump back to the main to ca...

...to syslinux_run_command()? Does it have a trailing line end character? terminating NUL character? > I've tried the ifcpu.c32 application as well (which is a bit similar to kontron_wdt.c32) and it also cannot call syslinux_run_command(). > > I can see that syslinux_run_command() call create_args_and_load() but if I put any printf's there they're not printed to screen, so it's pretty hard to debug what's causing the error. Are you using printf() or dprintf()? > If someone knows a way to call two labels that would also work as a workaround for the problem I'm trying to solve....

...dt.c32 I can see that > syslinux_run_command(..) returns -1. What could cause this? > > I've tried the ifcpu.c32 application as well (which is a bit similar > to kontron_wdt.c32) and it also cannot call syslinux_run_command(). > > I can see that syslinux_run_command() call create_args_and_load() but > if I put any printf's there they're not printed to screen, so it's > pretty hard to debug what's causing the error. > > If someone knows a way to call two labels that would also work as a > workaround for the problem I'm trying to solve. > > -- B...

...04: http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=975a4c3b343c09a340d95f1a2a4ece3556c57a10 And syslinux_run_command() in 2007: http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=0b3b862ff49ab1b0b5d5af8c15d58e3c4baaf634 At this point, syslinux_run_command is using the equivalent of create_args_and_load(), a function that is *not* negatively affected by ALLOWOPTIONS. The behavior was changed in 2013 to use load_kernel to *add* label support: http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=04f40bc55ed4f39d6c625b017bb16907f7d50c05 At this point the 8 or 9 com32 modules I listed earlier st...

Fix return from execute() if type == KT_NONE. Signed-off-by: Sebastian Herbszt <herbszt at gmx.de> --- com32/elflink/ldlinux/execute.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/com32/elflink/ldlinux/execute.c b/com32/elflink/ldlinux/execute.c index f713eb1..899154c 100644 --- a/com32/elflink/ldlinux/execute.c +++ b/com32/elflink/ldlinux/execute.c @@ -108,7

...a=commit;h=975a4c3b343c09a340d95f1a2a4ece3556c57a10 > > And syslinux_run_command() in 2007: > > http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=0b3b862ff49ab1b0b5d5af8c15d58e3c4baaf634 > > > > At this point, syslinux_run_command is using the equivalent of > > create_args_and_load(), a function that is *not* negatively affected > > by ALLOWOPTIONS. > > > > The behavior was changed in 2013 to use load_kernel to *add* label support: > > http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=04f40bc55ed4f39d6c625b017bb16907f7d50c05 > > > &gt...

...dt.c32 I can see that > syslinux_run_command(..) returns -1. What could cause this? > > I've tried the ifcpu.c32 application as well (which is a bit similar > to kontron_wdt.c32) and it also cannot call syslinux_run_command(). > > I can see that syslinux_run_command() call create_args_and_load() but > if I put any printf's there they're not printed to screen, so it's > pretty hard to debug what's causing the error. > > If someone knows a way to call two labels that would also work as a > workaround for the problem I'm trying to solve. > > --...

From: Matt Fleming <matt.fleming at intel.com> The first two patches in this series are fixes for bugs reported by someone in #syslinux. The third makes dmitest.c32 actually wait for user input. If no one has any objections/concerns, I'll pull this into the official elflink branch. Matt Fleming (3): core: Print error message if we don't load ldlinux.c32 Clean up $(GPLLIB) leak

From: Sylvain Gault <sylvain.gault at gmail.com> Hello there, I propose 2 patches that fix two possible stack overflows either when running a COM32 module or when loading a new config file. I didn't find a better way to do this than to use the infamous setjmp/longjmp functions to restore the stack to a previous state. This makes the logic a bit more complex, but the behavior is not

From: Matt Fleming <matt.fleming at intel.com> Since we can't use __intcall() for EFI, and since we can now have the ELF module code resolve all our symbols at runtime, we should delete as many references to __intcall() as possible and just access the symbols directly. The most interesting patch is the support for weak symbols. We need to be able to reference derivative-specific

...ss", IMAGE_TYPE_BSS }, + { "pxe", IMAGE_TYPE_PXE }, + { "fdimage", IMAGE_TYPE_FDIMAGE }, + { "comboot", IMAGE_TYPE_COMBOOT }, + { "com32", IMAGE_TYPE_COM32 }, + { "config", IMAGE_TYPE_CONFIG }, + { NULL, 0 }, }; extern int create_args_and_load(char *); -void execute(const char *cmdline, enum kernel_type type) +void execute(const char *cmdline, uint32_t type) { - const char *p, *const *pp; const char *kernel, *args; + const char *p; com32sys_t ireg; char *q; @@ -79,22 +79,31 @@ void execute(const char *cmdline, enum kernel_type...

...uot; #include "fs.h" +#include "config.h" /* Must match enum kernel_type */ const char *const kernel_types[] = { @@ -84,8 +85,8 @@ void execute(const char *cmdline, enum kernel_type type) if (type == KT_COM32) { /* new entry for elf format c32 */ - lfree(kernel); - create_args_and_load(cmdline); + lfree((void *)kernel); + create_args_and_load((char *)cmdline); } else if (type == KT_CONFIG) { char *argv[] = { "ldlinux.c32", NULL }; @@ -96,7 +97,7 @@ void execute(const char *cmdline, enum kernel_type type) if (*args) mangle_name(config_cwd, args); - sta...

From: Matt Fleming <matt.fleming at intel.com> The following patch series is available at, git://git.zytor.com/users/mfleming/syslinux.git elflink All patches are against the 'elflink' branch. This series fixes a few serious bugs and some behavioural incompatibilities with the 4.x series. Matt Fleming (19): ldlinux: Initialise 'p' before using it. ldlinux: Parse