[U-Boot] [PATCH 1/6] dlmalloc: ensure gd is set for early alloc
Attempting to run the sandbox leads to a segfault, because some dynamic libraries (outside of u-boot) attempt to use malloc() to allocate memory before u-boot's gd variable is initialized.
Check for gd not being NULL in the SYS_MALLOC_F_LEN handling, so that malloc() doesn't crash when called at this point.
$ gdb -q --args ./u-boot (gdb) r Program received signal SIGSEGV, Segmentation fault. 0x0000000000412b9b in malloc (bytes=bytes@entry=37) at common/dlmalloc.c:2184 2184 if (!(gd->flags & GD_FLG_RELOC)) { (gdb) p gd $1 = (gd_t *) 0x0 (gdb) bt #0 0x0000000000412b9b in malloc (bytes=bytes@entry=37) at common/dlmalloc.c:2184 #1 0x00007ffff75bf8e1 in set_binding_values (domainname=0x7ffff11f4f12 "libgpg-error", dirnamep=0x7fffffffe168, codesetp=0x0) at bindtextdom.c:228 #2 0x00007ffff75bfb4c in set_binding_values (codesetp=0x0, dirnamep=0x7fffffffe168, domainname=<optimized out>) at bindtextdom.c:350 #3 __bindtextdomain (domainname=<optimized out>, dirname=0x7ffff11f4f00 "/usr/share/locale") at bindtextdom.c:348 #4 0x00007ffff11eca17 in ?? () from /lib/x86_64-linux-gnu/libgpg-error.so.0 #5 0x00007ffff7dea9fa in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffe208, env=env@entry=0x7fffffffe218) at dl-init.c:78 #6 0x00007ffff7deaae3 in call_init (env=0x7fffffffe218, argv=0x7fffffffe208, argc=1, l=<optimized out>) at dl-init.c:36 #7 _dl_init (main_map=0x7ffff7ffe1a8, argc=1, argv=0x7fffffffe208, env=0x7fffffffe218) at dl-init.c:126 #8 0x00007ffff7ddd1ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
Signed-off-by: Rabin Vincent rabin@rab.in --- common/dlmalloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c index f987339..d87834d 100644 --- a/common/dlmalloc.c +++ b/common/dlmalloc.c @@ -2181,7 +2181,7 @@ Void_t* mALLOc(bytes) size_t bytes; INTERNAL_SIZE_T nb;
#ifdef CONFIG_SYS_MALLOC_F_LEN - if (!(gd->flags & GD_FLG_RELOC)) { + if (gd && !(gd->flags & GD_FLG_RELOC)) { ulong new_ptr; void *ptr;
sandbox crashes if a variable is set in the -c command, because hush's top_vars is not allocated. Call cli_init() from sandbox to ensure this is done before we execute the -c command.
$ ./u-boot -c 'a=1' ... Segmentation fault (core dumped)
Signed-off-by: Rabin Vincent rabin@rab.in --- arch/sandbox/cpu/start.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c index b3d7051..53a99ae 100644 --- a/arch/sandbox/cpu/start.c +++ b/arch/sandbox/cpu/start.c @@ -5,6 +5,7 @@
#include <common.h> #include <os.h> +#include <cli.h> #include <asm/getopt.h> #include <asm/io.h> #include <asm/sections.h> @@ -76,6 +77,8 @@ int sandbox_main_loop_init(void)
/* Execute command if required */ if (state->cmd) { + cli_init(); + run_command_list(state->cmd, -1, 0); if (!state->interactive) os_exit(state->exit_type);
On 29 October 2014 16:21, Rabin Vincent rabin@rab.in wrote:
sandbox crashes if a variable is set in the -c command, because hush's top_vars is not allocated. Call cli_init() from sandbox to ensure this is done before we execute the -c command.
$ ./u-boot -c 'a=1' ... Segmentation fault (core dumped)
Signed-off-by: Rabin Vincent rabin@rab.in
Acked-by: Simon Glass <sjg@chromium.org) Tested-by: Simon Glass <sjg@chromium.org)
On Wed, Oct 29, 2014 at 11:21:38PM +0100, Rabin Vincent wrote:
sandbox crashes if a variable is set in the -c command, because hush's top_vars is not allocated. Call cli_init() from sandbox to ensure this is done before we execute the -c command.
$ ./u-boot -c 'a=1' ... Segmentation fault (core dumped)
Signed-off-by: Rabin Vincent rabin@rab.in Acked-by: Simon Glass <sjg@chromium.org) Tested-by: Simon Glass <sjg@chromium.org)
Applied to u-boot/master, thanks!
Attempting to run: - an empty string - a string with just spaces
returns different error codes, 1 for the empty string and 0 for the string with just spaces. Make both of them return 0 for consistency.
Signed-off-by: Rabin Vincent rabin@rab.in --- common/cli_hush.c | 4 +++- test/command_ut.c | 3 +++ 2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/common/cli_hush.c b/common/cli_hush.c index 2b654b7..9607e93 100644 --- a/common/cli_hush.c +++ b/common/cli_hush.c @@ -3236,8 +3236,10 @@ int parse_string_outer(const char *s, int flag) #ifdef __U_BOOT__ char *p = NULL; int rcode; - if ( !s || !*s) + if (!s) return 1; + if (!*s) + return 0; if (!(p = strchr(s, '\n')) || *++p) { p = xmalloc(strlen(s) + 2); strcpy(p, s); diff --git a/test/command_ut.c b/test/command_ut.c index e136075..a4f0341 100644 --- a/test/command_ut.c +++ b/test/command_ut.c @@ -188,6 +188,9 @@ static int do_ut_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) #endif #endif
+ assert(run_command("", 0) == 0); + assert(run_command(" ", 0) == 0); + printf("%s: Everything went swimmingly\n", __func__); return 0; }
On 29 October 2014 16:21, Rabin Vincent rabin@rab.in wrote:
Attempting to run:
- an empty string
- a string with just spaces
returns different error codes, 1 for the empty string and 0 for the string with just spaces. Make both of them return 0 for consistency.
Signed-off-by: Rabin Vincent rabin@rab.in
Acked-by: Simon Glass <sjg@chromium.org)
On Wed, Oct 29, 2014 at 11:21:39PM +0100, Rabin Vincent wrote:
Attempting to run:
- an empty string
- a string with just spaces
returns different error codes, 1 for the empty string and 0 for the string with just spaces. Make both of them return 0 for consistency.
Signed-off-by: Rabin Vincent rabin@rab.in Acked-by: Simon Glass <sjg@chromium.org)
Applied to u-boot/master, thanks!
Hush segfaults if it sees a syntax error while attempting to parse a command:
$ ./u-boot -c "'" ... syntax error Segmentation fault (core dumped)
This is due to a NULL pointer dereference of in_str->p in static_peek(). The problem is that the exit condition for the loop in parse_stream_outer() checks for rcode not being -1, but rcode is only ever 0 or 1.
Signed-off-by: Rabin Vincent rabin@rab.in --- common/cli_hush.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/cli_hush.c b/common/cli_hush.c index 9607e93..a07ae71 100644 --- a/common/cli_hush.c +++ b/common/cli_hush.c @@ -3217,7 +3217,7 @@ static int parse_stream_outer(struct in_str *inp, int flag) } b_free(&temp); /* loop on syntax errors, return on EOF */ - } while (rcode != -1 && !(flag & FLAG_EXIT_FROM_LOOP) && + } while (rcode != 1 && !(flag & FLAG_EXIT_FROM_LOOP) && (inp->peek != static_peek || b_peek(inp))); #ifndef __U_BOOT__ return 0;
Hi Rabin,
On 29 October 2014 16:21, Rabin Vincent rabin@rab.in wrote:
Hush segfaults if it sees a syntax error while attempting to parse a command:
$ ./u-boot -c "'" ... syntax error Segmentation fault (core dumped)
This is due to a NULL pointer dereference of in_str->p in static_peek(). The problem is that the exit condition for the loop in parse_stream_outer() checks for rcode not being -1, but rcode is only ever 0 or 1.
Signed-off-by: Rabin Vincent rabin@rab.in
Acked-by: Simon Glass <sjg@chromium.org) Tested-by: Simon Glass <sjg@chromium.org)
BTW I notice that I still get a crash with
./u-boot -c "''"
Regards, Simon
On Wed, Oct 29, 2014 at 11:21:40PM +0100, Rabin Vincent wrote:
Hush segfaults if it sees a syntax error while attempting to parse a command:
$ ./u-boot -c "'" ... syntax error Segmentation fault (core dumped)
This is due to a NULL pointer dereference of in_str->p in static_peek(). The problem is that the exit condition for the loop in parse_stream_outer() checks for rcode not being -1, but rcode is only ever 0 or 1.
Signed-off-by: Rabin Vincent rabin@rab.in Acked-by: Simon Glass <sjg@chromium.org) Tested-by: Simon Glass <sjg@chromium.org)
Applied to u-boot/master, thanks!
run_command() returns success even if the command had a syntax error; correct this behaviour.
Signed-off-by: Rabin Vincent rabin@rab.in --- common/cli_hush.c | 2 +- test/command_ut.c | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/common/cli_hush.c b/common/cli_hush.c index a07ae71..d643912 100644 --- a/common/cli_hush.c +++ b/common/cli_hush.c @@ -3162,7 +3162,7 @@ static int parse_stream_outer(struct in_str *inp, int flag) o_string temp=NULL_O_STRING; int rcode; #ifdef __U_BOOT__ - int code = 0; + int code = 1; #endif do { ctx.type = flag; diff --git a/test/command_ut.c b/test/command_ut.c index a4f0341..926573a 100644 --- a/test/command_ut.c +++ b/test/command_ut.c @@ -191,6 +191,8 @@ static int do_ut_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) assert(run_command("", 0) == 0); assert(run_command(" ", 0) == 0);
+ assert(run_command("'", 0) == 1); + printf("%s: Everything went swimmingly\n", __func__); return 0; }
On 29 October 2014 16:21, Rabin Vincent rabin@rab.in wrote:
run_command() returns success even if the command had a syntax error; correct this behaviour.
Signed-off-by: Rabin Vincent rabin@rab.in
Acked-by: Simon Glass <sjg@chromium.org)
On Wed, Oct 29, 2014 at 11:21:41PM +0100, Rabin Vincent wrote:
run_command() returns success even if the command had a syntax error; correct this behaviour.
Signed-off-by: Rabin Vincent rabin@rab.in Acked-by: Simon Glass <sjg@chromium.org)
Applied to u-boot/master, thanks!
Add a couple of tests for quoting. The indirect variable read test is a fixed version of the following expression from Fedora ARM's boot.scr. This unfixed expression stopped working after fe9ca3d ("hush: fix some quoted variable expansion issues"):
setenv catcat setenv catout;'setenv catX "setenv catout '\\\''$$catin'\\\''"' ; run catX
Signed-off-by: Rabin Vincent rabin@rab.in --- test/command_ut.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/test/command_ut.c b/test/command_ut.c index 926573a..21804a4 100644 --- a/test/command_ut.c +++ b/test/command_ut.c @@ -193,6 +193,16 @@ static int do_ut_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
assert(run_command("'", 0) == 1);
+ assert(run_command("setenv ut_var '"'; setenv ut_var2 "${ut_var}"", 0) == 0); + assert(!strcmp(getenv("ut_var2"), """)); + + assert(run_command("setenv ut_catcat setenv ut_catout\;setenv ut_catX setenv ut_catout \\\\\\\"\$\$ut_catin\\\\\\\" \; run ut_catX", 0) == 0); + assert(run_command("setenv ut_pointer '1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20'", 0) == 0); + assert(run_command("setenv ut_catin ut_pointer", 0) == 0); + assert(run_command("run ut_catcat", 0) == 0); + assert(getenv("ut_catout")); + assert(!strcmp(getenv("ut_catout"), "1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20")); + printf("%s: Everything went swimmingly\n", __func__); return 0; }
Hi Rabin,
On 29 October 2014 16:21, Rabin Vincent rabin@rab.in wrote:
Add a couple of tests for quoting. The indirect variable read test is a fixed version of the following expression from Fedora ARM's boot.scr. This unfixed expression stopped working after fe9ca3d ("hush: fix some quoted variable expansion issues"):
setenv catcat setenv catout;'setenv catX "setenv catout '\\\''$$catin'\\\''"' ; run catX
Signed-off-by: Rabin Vincent rabin@rab.in
test/command_ut.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/test/command_ut.c b/test/command_ut.c index 926573a..21804a4 100644 --- a/test/command_ut.c +++ b/test/command_ut.c @@ -193,6 +193,16 @@ static int do_ut_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
assert(run_command("'", 0) == 1);
assert(run_command("setenv ut_var '\"'; setenv ut_var2 \"${ut_var}\"", 0) == 0);assert(!strcmp(getenv("ut_var2"), "\""));assert(run_command("setenv ut_catcat setenv ut_catout\\;setenv ut_catX setenv ut_catout \\\\\\\\\\\\\\\"\\$\\$ut_catin\\\\\\\\\\\\\\\" \\; run ut_catX", 0) == 0);assert(run_command("setenv ut_pointer '1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20'", 0) == 0);
Can we reduce this down to 3-4 numbers for easier maintenance? Or do the 20 numbers buy us something?
Also did you test this with the simple cli parser too?
assert(run_command("setenv ut_catin ut_pointer", 0) == 0);assert(run_command("run ut_catcat", 0) == 0);assert(getenv("ut_catout"));assert(!strcmp(getenv("ut_catout"), "1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20"));printf("%s: Everything went swimmingly\n", __func__); return 0;}
2.1.1
Regards, Simon
On Sat, Nov 01, 2014 at 09:12:37AM -0600, Simon Glass wrote:
On 29 October 2014 16:21, Rabin Vincent rabin@rab.in wrote:
assert(run_command("setenv ut_var '\"'; setenv ut_var2 \"${ut_var}\"", 0) == 0);assert(!strcmp(getenv("ut_var2"), "\""));assert(run_command("setenv ut_catcat setenv ut_catout\\;setenv ut_catX setenv ut_catout \\\\\\\\\\\\\\\"\\$\\$ut_catin\\\\\\\\\\\\\\\" \\; run ut_catX", 0) == 0);assert(run_command("setenv ut_pointer '1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20'", 0) == 0);Can we reduce this down to 3-4 numbers for easier maintenance? Or do the 20 numbers buy us something?
After 14 arguments, the quotes around them become necessary, so having more than 14 ensures we test that the quotes are still there:
=> setenv x 1 2 3 4 5 6 7 8 9 10 11 12 13 => setenv x 1 2 3 4 5 6 7 8 9 10 11 12 13 14 => setenv x 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 setenv - set environment variables
Usage: setenv [-f] name value ... - [forcibly] set environment variable 'name' to 'value ...' setenv [-f] name - [forcibly] delete environment variable 'name' => setenv x '1 2 3 4 5 6 7 8 9 10 11 12 13 14 15' =>
Also did you test this with the simple cli parser too?
No, I didn't realize that these tests they would get run without hush. I tried them out and they fail with the simple parser, as do the tests with the empty strings in the third patch. What do you suggest? Drop these new tests, or move them inside the ifdef HUSH?
Hi,
On 5 November 2014 13:11, Rabin Vincent rabin@rab.in wrote:
On Sat, Nov 01, 2014 at 09:12:37AM -0600, Simon Glass wrote:
On 29 October 2014 16:21, Rabin Vincent rabin@rab.in wrote:
assert(run_command("setenv ut_var '\"'; setenv ut_var2 \"${ut_var}\"", 0) == 0);assert(!strcmp(getenv("ut_var2"), "\""));assert(run_command("setenv ut_catcat setenv ut_catout\\;setenv ut_catX setenv ut_catout \\\\\\\\\\\\\\\"\\$\\$ut_catin\\\\\\\\\\\\\\\" \\; run ut_catX", 0) == 0);assert(run_command("setenv ut_pointer '1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20'", 0) == 0);Can we reduce this down to 3-4 numbers for easier maintenance? Or do the 20 numbers buy us something?
After 14 arguments, the quotes around them become necessary, so having more than 14 ensures we test that the quotes are still there:
=> setenv x 1 2 3 4 5 6 7 8 9 10 11 12 13 => setenv x 1 2 3 4 5 6 7 8 9 10 11 12 13 14 => setenv x 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 setenv - set environment variables
OK sounds good. How about adding a test that CONFIG_SYS_MAXARGS is < you number.
Like
#if CONFIG_SYS_MAXARGS > 15 #error "..." #endif
Otherwise if someone changes it in sandbox the test will change.
Usage: setenv [-f] name value ... - [forcibly] set environment variable 'name' to 'value ...' setenv [-f] name - [forcibly] delete environment variable 'name' => setenv x '1 2 3 4 5 6 7 8 9 10 11 12 13 14 15' =>
Also did you test this with the simple cli parser too?
No, I didn't realize that these tests they would get run without hush. I tried them out and they fail with the simple parser, as do the tests with the empty strings in the third patch. What do you suggest? Drop these new tests, or move them inside the ifdef HUSH?
#ifdef HUSH if the tests can't work without it.
Regards, Simon
Hi Rabin,
On 29 October 2014 16:21, Rabin Vincent rabin@rab.in wrote:
Attempting to run the sandbox leads to a segfault, because some dynamic libraries (outside of u-boot) attempt to use malloc() to allocate memory before u-boot's gd variable is initialized.
Check for gd not being NULL in the SYS_MALLOC_F_LEN handling, so that malloc() doesn't crash when called at this point.
$ gdb -q --args ./u-boot (gdb) r Program received signal SIGSEGV, Segmentation fault. 0x0000000000412b9b in malloc (bytes=bytes@entry=37) at common/dlmalloc.c:2184 2184 if (!(gd->flags & GD_FLG_RELOC)) { (gdb) p gd $1 = (gd_t *) 0x0 (gdb) bt #0 0x0000000000412b9b in malloc (bytes=bytes@entry=37) at common/dlmalloc.c:2184 #1 0x00007ffff75bf8e1 in set_binding_values (domainname=0x7ffff11f4f12 "libgpg-error", dirnamep=0x7fffffffe168, codesetp=0x0) at bindtextdom.c:228 #2 0x00007ffff75bfb4c in set_binding_values (codesetp=0x0, dirnamep=0x7fffffffe168, domainname=<optimized out>) at bindtextdom.c:350 #3 __bindtextdomain (domainname=<optimized out>, dirname=0x7ffff11f4f00 "/usr/share/locale") at bindtextdom.c:348 #4 0x00007ffff11eca17 in ?? () from /lib/x86_64-linux-gnu/libgpg-error.so.0 #5 0x00007ffff7dea9fa in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffe208, env=env@entry=0x7fffffffe218) at dl-init.c:78 #6 0x00007ffff7deaae3 in call_init (env=0x7fffffffe218, argv=0x7fffffffe208, argc=1, l=<optimized out>) at dl-init.c:36 #7 _dl_init (main_map=0x7ffff7ffe1a8, argc=1, argv=0x7fffffffe208, env=0x7fffffffe218) at dl-init.c:126 #8 0x00007ffff7ddd1ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
Signed-off-by: Rabin Vincent rabin@rab.in
Acked-by: Simon Glass sjg@chromium.org
How do you provoke this error? It doesn't seem to happen for me.
Regards, Simon
On Sat, Nov 01, 2014 at 09:11:34AM -0600, Simon Glass wrote:
On 29 October 2014 16:21, Rabin Vincent rabin@rab.in wrote:
Attempting to run the sandbox leads to a segfault, because some dynamic libraries (outside of u-boot) attempt to use malloc() to allocate memory before u-boot's gd variable is initialized.
Check for gd not being NULL in the SYS_MALLOC_F_LEN handling, so that malloc() doesn't crash when called at this point.
$ gdb -q --args ./u-boot (gdb) r Program received signal SIGSEGV, Segmentation fault. 0x0000000000412b9b in malloc (bytes=bytes@entry=37) at common/dlmalloc.c:2184 2184 if (!(gd->flags & GD_FLG_RELOC)) { (gdb) p gd $1 = (gd_t *) 0x0 (gdb) bt #0 0x0000000000412b9b in malloc (bytes=bytes@entry=37) at common/dlmalloc.c:2184 #1 0x00007ffff75bf8e1 in set_binding_values (domainname=0x7ffff11f4f12 "libgpg-error", dirnamep=0x7fffffffe168, codesetp=0x0) at bindtextdom.c:228 #2 0x00007ffff75bfb4c in set_binding_values (codesetp=0x0, dirnamep=0x7fffffffe168, domainname=<optimized out>) at bindtextdom.c:350 #3 __bindtextdomain (domainname=<optimized out>, dirname=0x7ffff11f4f00 "/usr/share/locale") at bindtextdom.c:348 #4 0x00007ffff11eca17 in ?? () from /lib/x86_64-linux-gnu/libgpg-error.so.0 #5 0x00007ffff7dea9fa in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffe208, env=env@entry=0x7fffffffe218) at dl-init.c:78 #6 0x00007ffff7deaae3 in call_init (env=0x7fffffffe218, argv=0x7fffffffe208, argc=1, l=<optimized out>) at dl-init.c:36 #7 _dl_init (main_map=0x7ffff7ffe1a8, argc=1, argv=0x7fffffffe208, env=0x7fffffffe218) at dl-init.c:126 #8 0x00007ffff7ddd1ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
How do you provoke this error? It doesn't seem to happen for me.
I just run the u-boot binary, which I built with sandbox_defconfig. Perhaps you have different library versions on your system? (I see it's libgpg-error.so which is triggering the malloc() here.) I run Debian unstable.
On Wed, Oct 29, 2014 at 11:21:37PM +0100, Rabin Vincent wrote:
Attempting to run the sandbox leads to a segfault, because some dynamic libraries (outside of u-boot) attempt to use malloc() to allocate memory before u-boot's gd variable is initialized.
Check for gd not being NULL in the SYS_MALLOC_F_LEN handling, so that malloc() doesn't crash when called at this point.
$ gdb -q --args ./u-boot (gdb) r Program received signal SIGSEGV, Segmentation fault. 0x0000000000412b9b in malloc (bytes=bytes@entry=37) at common/dlmalloc.c:2184 2184 if (!(gd->flags & GD_FLG_RELOC)) { (gdb) p gd $1 = (gd_t *) 0x0 (gdb) bt #0 0x0000000000412b9b in malloc (bytes=bytes@entry=37) at common/dlmalloc.c:2184 #1 0x00007ffff75bf8e1 in set_binding_values (domainname=0x7ffff11f4f12 "libgpg-error", dirnamep=0x7fffffffe168, codesetp=0x0) at bindtextdom.c:228 #2 0x00007ffff75bfb4c in set_binding_values (codesetp=0x0, dirnamep=0x7fffffffe168, domainname=<optimized out>) at bindtextdom.c:350 #3 __bindtextdomain (domainname=<optimized out>, dirname=0x7ffff11f4f00 "/usr/share/locale") at bindtextdom.c:348 #4 0x00007ffff11eca17 in ?? () from /lib/x86_64-linux-gnu/libgpg-error.so.0 #5 0x00007ffff7dea9fa in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffe208, env=env@entry=0x7fffffffe218) at dl-init.c:78 #6 0x00007ffff7deaae3 in call_init (env=0x7fffffffe218, argv=0x7fffffffe208, argc=1, l=<optimized out>) at dl-init.c:36 #7 _dl_init (main_map=0x7ffff7ffe1a8, argc=1, argv=0x7fffffffe208, env=0x7fffffffe218) at dl-init.c:126 #8 0x00007ffff7ddd1ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
Signed-off-by: Rabin Vincent rabin@rab.in Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
participants (3)
-
Rabin Vincent -
Simon Glass -
Tom Rini