signal commands are broken

[tromey]

It turns out that gdb sends a trailing ";" with a signal list:

Sending packet: $QProgramSignals:0;1;3;4;6;7;8;9;a;b;c;d;e;f;10;11;12;13;14;15;16;17;18;19;1a;1b;1c;1d;1e;1f;20;21;22;23;24;25;26;27;28;29;2a;2b;2c;2d;2e;2f;30;31;32;33;34;35;36;37;38;39;3a;3b;3c;3d;3e;3f;40;41;42;43;44;45;46;47;48;49;4a;4b;4c;4d;4e;4f;50;51;52;53;54;55;56;57;58;59;5a;5b;5c;5d;5e;5f;60;61;62;63;64;65;66;67;68;69;6a;6b;6c;6d;6e;6f;70;71;72;73;74;75;76;77;78;79;7a;7b;7c;7d;7e;7f;80;81;82;83;84;85;86;87;88;89;8a;8b;8c;8d;8e;8f;90;91;92;93;94;95;96;97;#75...Packet received: 

However, the current parser doesn't accept this.

I'm not sure how to accept an optional trailing separator with nom. Any ideas?

Changing the parser would at least work; and I will probably do this, but it isn't really robust as this seems to be a bug in gdb.

[tromey]

Well, maybe it is ok actually, since the problem gdb was seeing turned out to be elsewhere. However it also turns out that the current parser doesn't match all the input, which seems incorrect. If a parser fails to match everything then it should probably be an error.

[luser]

If a parser fails to match everything then it should probably be an error.

Yeah, agreed.

[tromey]

I'm not sure how to accept an optional trailing separator with nom. Any ideas?

In this particular case I guess I could have it match a hex value followed by an optional ;.

[tromey]

In this particular case I guess I could have it match a hex value followed by an optional ;.

This turns out to be surprisingly hard. nom confuses me sometimes.