Re: [alsa-devel] [Sound-open-firmware] [PATCH v3 13/14] ASoC: SOF: Add xtensa support
在 12/13/2018 2:15 PM, rander.wang 写道:
在 12/12/2018 8:00 AM, Pierre-Louis Bossart 写道:
On 12/11/18 5:08 PM, Andy Shevchenko wrote:
On Tue, Dec 11, 2018 at 03:23:17PM -0600, Pierre-Louis Bossart wrote:
Add common directory for xtensa architecture + for (i = 0; i <= stack_words - 4; i += 4) { + dev_err(sdev->dev, "0x%8.8x: 0x%8.8x 0x%8.8x 0x%8.8x 0x%8.8x\n", + stack_ptr + i, stack[i], stack[i + 1], stack[i + 2], + stack[i + 3]); + }
+ /* deal with any remaining words */ + switch (stack_words - i) { + case 0: + break; + case 1: + dev_err(sdev->dev, "0x%8.8x: 0x%8.8x\n", + stack_ptr + stack_words - 1, stack[stack_words - 1]); + break; + case 2: + dev_err(sdev->dev, "0x%8.8x: 0x%8.8x 0x%8.8x\n", + stack_ptr + stack_words - 2, stack[stack_words - 2], + stack[stack_words - 1]); + break; + case 3: + dev_err(sdev->dev, "0x%8.8x: 0x%8.8x 0x%8.8x 0x%8.8x\n", + stack_ptr + stack_words - 3, stack[stack_words - 3], + stack[stack_words - 2], stack[stack_words - 1]); + break; + default: + break; + }
hex_dump_to_buffer().
I vaguely recall there was a reason not to do it, we'll relook at this.
we don't want to convert a blob of data to "hex ASCII" in memory (hex_dump_to_buffer).
Here, we just want to dump the content of call stack, like:
[ 3.250628] sof-audio sof-audio: 0x0049fbb0: 0x8000f2d0 0x0049fc00 0x6f6c6c61 0x00632e63 [ 3.250670] sof-audio sof-audio: 0x0049fbb4: 0x00ffffff 0x0010b5d4 0x00000000 0x2000004c [ 3.250710] sof-audio sof-audio: 0x0049fbb8: 0x0040d000 0x00000000 0x0000024c 0x2000930c [ 3.250747] sof-audio sof-audio: 0x0049fbbc: 0x8000454c 0x0049fc30 0x00401e20 0x00000001 [ 3.250787] sof-audio sof-audio: 0x0049fbc0: 0x8000454c 0x0049fc30 0x00401e20 0x00000001 [ 3.250827] sof-audio sof-audio: 0x0049fbc4: 0x00000000 0x00000001 0x00000010 0x0049fcb8 [ 3.250865] sof-audio sof-audio: 0x0049fbc8: 0x0040a000 0x00401e98 0x00000001 0x00000002 [ 3.250889] sof-audio sof-audio: 0x0049fbcc: 0x80005ac5 0x0049fc60 0x00000000 0x00000000
Add more details: we use another tool to analysis the hex numbers with a ELF file to get the correct information, so we do it by ourself.
Thanks!
Rander
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Thu, 13 Dec 2018 10:58:44 +0100, rander.wang wrote:
在 12/13/2018 2:15 PM, rander.wang 写道:
在 12/12/2018 8:00 AM, Pierre-Louis Bossart 写道:
On 12/11/18 5:08 PM, Andy Shevchenko wrote:
On Tue, Dec 11, 2018 at 03:23:17PM -0600, Pierre-Louis Bossart wrote:
Add common directory for xtensa architecture + for (i = 0; i <= stack_words - 4; i += 4) { + dev_err(sdev->dev, "0x%8.8x: 0x%8.8x 0x%8.8x 0x%8.8x 0x%8.8x\n", + stack_ptr + i, stack[i], stack[i + 1], stack[i + 2], + stack[i + 3]); + }
+ /* deal with any remaining words */ + switch (stack_words - i) { + case 0: + break; + case 1: + dev_err(sdev->dev, "0x%8.8x: 0x%8.8x\n", + stack_ptr + stack_words - 1, stack[stack_words - 1]); + break; + case 2: + dev_err(sdev->dev, "0x%8.8x: 0x%8.8x 0x%8.8x\n", + stack_ptr + stack_words - 2, stack[stack_words - 2], + stack[stack_words - 1]); + break; + case 3: + dev_err(sdev->dev, "0x%8.8x: 0x%8.8x 0x%8.8x 0x%8.8x\n", + stack_ptr + stack_words - 3, stack[stack_words - 3], + stack[stack_words - 2], stack[stack_words - 1]); + break; + default: + break; + }
hex_dump_to_buffer().
I vaguely recall there was a reason not to do it, we'll relook at this.
we don't want to convert a blob of data to "hex ASCII" in memory (hex_dump_to_buffer).
Here, we just want to dump the content of call stack, like:
[ 3.250628] sof-audio sof-audio: 0x0049fbb0: 0x8000f2d0 0x0049fc00 0x6f6c6c61 0x00632e63 [ 3.250670] sof-audio sof-audio: 0x0049fbb4: 0x00ffffff 0x0010b5d4 0x00000000 0x2000004c [ 3.250710] sof-audio sof-audio: 0x0049fbb8: 0x0040d000 0x00000000 0x0000024c 0x2000930c [ 3.250747] sof-audio sof-audio: 0x0049fbbc: 0x8000454c 0x0049fc30 0x00401e20 0x00000001 [ 3.250787] sof-audio sof-audio: 0x0049fbc0: 0x8000454c 0x0049fc30 0x00401e20 0x00000001 [ 3.250827] sof-audio sof-audio: 0x0049fbc4: 0x00000000 0x00000001 0x00000010 0x0049fcb8 [ 3.250865] sof-audio sof-audio: 0x0049fbc8: 0x0040a000 0x00401e98 0x00000001 0x00000002 [ 3.250889] sof-audio sof-audio: 0x0049fbcc: 0x80005ac5 0x0049fc60 0x00000000 0x00000000
Add more details: we use another tool to analysis the hex numbers with a ELF file to get the correct information, so we do it by ourself.
If the format is intentional and shouldn't be changed to the generic one, this has to be mentioned in the code as some proper comment.
The use of hex_dump_to_buffer() or whatever the standard macro is a "right thing" in general. From what I can see, the home-baked code does nothing but writing in 32bit words, so without the explanation, no one can see the reason to stick with it.
thanks,
Takashi
On Mon, Dec 17, 2018 at 02:45:49PM +0100, Takashi Iwai wrote:
rander.wang wrote:
[ 3.250889] sof-audio sof-audio: 0x0049fbcc: 0x80005ac5 0x0049fc60 0x00000000 0x00000000
Add more details: we use another tool to analysis the hex numbers with a ELF file to get the correct information, so we do it by ourself.
If the format is intentional and shouldn't be changed to the generic one, this has to be mentioned in the code as some proper comment.
The use of hex_dump_to_buffer() or whatever the standard macro is a "right thing" in general. From what I can see, the home-baked code does nothing but writing in 32bit words, so without the explanation, no one can see the reason to stick with it.
Or alternatively can the tool be changed to parse the more standard format if it's not too hard to get people to update?
participants (3)
-
Mark Brown -
rander.wang -
Takashi Iwai