{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":359509926,"defaultBranch":"zephyr-binutils-2_38","name":"binutils-gdb","ownerLogin":"zephyrproject-rtos","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2021-04-19T15:33:15.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/19595895?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1726669971.0","currentOid":""},"activityList":{"items":[{"before":"66646cfeb0769c1eb5c98cb40939a443f73ccfcd","after":"a6a80212f75e7bb6ce0b6be1f99bfc13e62fefdf","ref":"refs/heads/zephyr-gdb-12.1","pushedAt":"2024-09-18T15:26:13.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"stephanosio","name":"Stephanos Ioannidis","path":"/stephanosio","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11345418?s=80&v=4"},"commit":{"message":"gdbsupport: ignore -Wenum-constexpr-conversion in enum-flags.h\n\nWhen building with clang 16, we get:\n\n CXX gdb.o\n In file included from /home/smarchi/src/binutils-gdb/gdb/gdb.c:19:\n In file included from /home/smarchi/src/binutils-gdb/gdb/defs.h:65:\n /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/enum-flags.h:95:52: error: integer value -1 is outside the valid range of values [0, 15] for this enumeration type [-Wenum-constexpr-conversion]\n integer_for_size(T (-1) < T (0))>::type\n ^\n\nThe error message does not make it clear in the context of which enum\nflag this fails (i.e. what is T in this context), but it doesn't really\nmatter, we have similar warning/errors for many of them, if we let the\nbuild go through.\n\nclang is right that the value -1 is invalid for the enum type we cast -1\nto. However, we do need this expression in order to select an integer\ntype with the appropriate signedness. That is, with the same signedness\nas the underlying type of the enum.\n\nI first wondered if that was really needed, if we couldn't use\nstd::underlying_type for that. It turns out that the comment just above\nsays:\n\n /* Note that std::underlying_type is not what we want here,\n since that returns unsigned int even when the enum decays to signed\n int. */\n\nI was surprised, because std::is_signed>\nreturns the right thing. So I tried replacing all this with\nstd::underlying_type, see if that would work. Doing so causes some\nbuild failures in unittests/enum-flags-selftests.c:\n\n CXX unittests/enum-flags-selftests.o\n /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:254:1: error: static assertion failed due to requirement 'gdb::is_same, selftests::enum_flags_tests::RE, enum_flags, selftests::enum_flags_tests::RE2, enum_flags, selftests::enum_fla\n gs_tests::URE, int>, selftests::enum_flags_tests::check_valid_expr254::archetype, selftests::enum_flags_tests::RE, enum_flags, selfte\n sts::enum_flags_tests::RE2, enum_flags, selftests::enum_flags_tests::URE, unsigned int>>::value == true':\n CHECK_VALID (true, int, true ? EF () : EF2 ())\n ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:91:3: note: expanded from macro 'CHECK_VALID'\n CHECK_VALID_EXPR_6 (EF, RE, EF2, RE2, UEF, URE, VALID, EXPR_TYPE, EXPR)\n ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:105:3: note: expanded from macro 'CHECK_VALID_EXPR_6'\n CHECK_VALID_EXPR_INT (ESC_PARENS (typename T1, typename T2, \\\n ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:66:3: note: expanded from macro 'CHECK_VALID_EXPR_INT'\n static_assert (gdb::is_detected_exact, \\\n ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThis is a bit hard to decode, but basically enumerations have the\nfollowing funny property that they decay into a signed int, even if\ntheir implicit underlying type is unsigned. This code:\n\n enum A {};\n enum B {};\n\n int main() {\n std::cout << std::is_signed::type>::value\n << std::endl;\n std::cout << std::is_signed::type>::value\n << std::endl;\n auto result = true ? A() : B();\n std::cout << std::is_signed::value << std::endl;\n }\n\nproduces:\n\n 0\n 0\n 1\n\nSo, the \"CHECK_VALID\" above checks that this property works for enum flags the\nsame way as it would if you were using their underlying enum types. And\nsomehow, changing integer_for_size to use std::underlying_type breaks that.\n\nSince the current code does what we want, and I don't see any way of doing it\ndifferently, ignore -Wenum-constexpr-conversion around it.\n\nChange-Id: Ibc82ae7bbdb812102ae3f1dd099fc859dc6f3cc2\n(cherry picked from commit ae61525fcf456ab395d55c45492a106d1275873a)\nSigned-off-by: Stephanos Ioannidis ","shortMessageHtmlLink":"gdbsupport: ignore -Wenum-constexpr-conversion in enum-flags.h"}},{"before":null,"after":"95a77a1b0d29bd7f6f2ec0fbe95175932a0b9921","ref":"refs/heads/clang_16_compat","pushedAt":"2024-09-18T14:32:51.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"stephanosio","name":"Stephanos Ioannidis","path":"/stephanosio","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11345418?s=80&v=4"},"commit":{"message":"gdbsupport: ignore -Wenum-constexpr-conversion in enum-flags.h\n\nWhen building with clang 16, we get:\n\n CXX gdb.o\n In file included from /home/smarchi/src/binutils-gdb/gdb/gdb.c:19:\n In file included from /home/smarchi/src/binutils-gdb/gdb/defs.h:65:\n /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/enum-flags.h:95:52: error: integer value -1 is outside the valid range of values [0, 15] for this enumeration type [-Wenum-constexpr-conversion]\n integer_for_size(T (-1) < T (0))>::type\n ^\n\nThe error message does not make it clear in the context of which enum\nflag this fails (i.e. what is T in this context), but it doesn't really\nmatter, we have similar warning/errors for many of them, if we let the\nbuild go through.\n\nclang is right that the value -1 is invalid for the enum type we cast -1\nto. However, we do need this expression in order to select an integer\ntype with the appropriate signedness. That is, with the same signedness\nas the underlying type of the enum.\n\nI first wondered if that was really needed, if we couldn't use\nstd::underlying_type for that. It turns out that the comment just above\nsays:\n\n /* Note that std::underlying_type is not what we want here,\n since that returns unsigned int even when the enum decays to signed\n int. */\n\nI was surprised, because std::is_signed>\nreturns the right thing. So I tried replacing all this with\nstd::underlying_type, see if that would work. Doing so causes some\nbuild failures in unittests/enum-flags-selftests.c:\n\n CXX unittests/enum-flags-selftests.o\n /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:254:1: error: static assertion failed due to requirement 'gdb::is_same, selftests::enum_flags_tests::RE, enum_flags, selftests::enum_flags_tests::RE2, enum_flags, selftests::enum_fla\n gs_tests::URE, int>, selftests::enum_flags_tests::check_valid_expr254::archetype, selftests::enum_flags_tests::RE, enum_flags, selfte\n sts::enum_flags_tests::RE2, enum_flags, selftests::enum_flags_tests::URE, unsigned int>>::value == true':\n CHECK_VALID (true, int, true ? EF () : EF2 ())\n ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:91:3: note: expanded from macro 'CHECK_VALID'\n CHECK_VALID_EXPR_6 (EF, RE, EF2, RE2, UEF, URE, VALID, EXPR_TYPE, EXPR)\n ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:105:3: note: expanded from macro 'CHECK_VALID_EXPR_6'\n CHECK_VALID_EXPR_INT (ESC_PARENS (typename T1, typename T2, \\\n ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:66:3: note: expanded from macro 'CHECK_VALID_EXPR_INT'\n static_assert (gdb::is_detected_exact, \\\n ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThis is a bit hard to decode, but basically enumerations have the\nfollowing funny property that they decay into a signed int, even if\ntheir implicit underlying type is unsigned. This code:\n\n enum A {};\n enum B {};\n\n int main() {\n std::cout << std::is_signed::type>::value\n << std::endl;\n std::cout << std::is_signed::type>::value\n << std::endl;\n auto result = true ? A() : B();\n std::cout << std::is_signed::value << std::endl;\n }\n\nproduces:\n\n 0\n 0\n 1\n\nSo, the \"CHECK_VALID\" above checks that this property works for enum flags the\nsame way as it would if you were using their underlying enum types. And\nsomehow, changing integer_for_size to use std::underlying_type breaks that.\n\nSince the current code does what we want, and I don't see any way of doing it\ndifferently, ignore -Wenum-constexpr-conversion around it.\n\nChange-Id: Ibc82ae7bbdb812102ae3f1dd099fc859dc6f3cc2\n(cherry picked from commit ae61525fcf456ab395d55c45492a106d1275873a)\nSigned-off-by: Stephanos Ioannidis ","shortMessageHtmlLink":"gdbsupport: ignore -Wenum-constexpr-conversion in enum-flags.h"}},{"before":"81f63d18c430569955cdcdac1bf2e0e524e0e6ef","after":null,"ref":"refs/heads/elf_phdr_rewrite_lma_neq_vma","pushedAt":"2024-01-31T18:43:40.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"stephanosio","name":"Stephanos Ioannidis","path":"/stephanosio","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11345418?s=80&v=4"}},{"before":"f36cd8b8f9c556a24f8df9097eb52da237c01982","after":"81f63d18c430569955cdcdac1bf2e0e524e0e6ef","ref":"refs/heads/zephyr-binutils-2_38","pushedAt":"2024-01-25T16:41:33.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"stephanosio","name":"Stephanos Ioannidis","path":"/stephanosio","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11345418?s=80&v=4"},"commit":{"message":"elf: Workaround for segment first section address check in phdr rewrite\n\nrewrite_elf_program_header() currently makes a questionable assumption\nthat the LMA of a segment will be aligned at the alignment of the first\nsection in the segment, and attempts to align the address of the segment\nLMA to the alignment of the first section using align_power() before\ncomparing it to the actual LMA of the first section for the purpose of\nverifying that the first section starts at the beginning of the segment.\n\nThis is not a problem when the LMA is equal to the VMA and both are\naligned at the section alignment; but, for the sections that have\ndifferent VMA and LMA, only the VMA is guaranteed to be aligned at the\nsection alignment, and the LMA may or may not be aligned at the same\nboundary, leading to rewrite_elf_program_header() returning false even\nfor valid ELF files that do not contain any segments whose first section\ndoes not start at the beginning of the segment.\n\nThis patch adds an alternate check directly comparing the segment and\nsection LMAs for the segments that do not contain any headers; in case a\nsegment contains a file or program header, the function may still\nerroneously return false.\n\nA more fundamental fix should re-implement the function such that it\nuses VMA for verifying that the first section in a segment starts at the\nbeginning of the segment.\n\nSigned-off-by: Stephanos Ioannidis ","shortMessageHtmlLink":"elf: Workaround for segment first section address check in phdr rewrite"}},{"before":null,"after":"81f63d18c430569955cdcdac1bf2e0e524e0e6ef","ref":"refs/heads/elf_phdr_rewrite_lma_neq_vma","pushedAt":"2024-01-25T13:53:40.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"stephanosio","name":"Stephanos Ioannidis","path":"/stephanosio","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11345418?s=80&v=4"},"commit":{"message":"elf: Workaround for segment first section address check in phdr rewrite\n\nrewrite_elf_program_header() currently makes a questionable assumption\nthat the LMA of a segment will be aligned at the alignment of the first\nsection in the segment, and attempts to align the address of the segment\nLMA to the alignment of the first section using align_power() before\ncomparing it to the actual LMA of the first section for the purpose of\nverifying that the first section starts at the beginning of the segment.\n\nThis is not a problem when the LMA is equal to the VMA and both are\naligned at the section alignment; but, for the sections that have\ndifferent VMA and LMA, only the VMA is guaranteed to be aligned at the\nsection alignment, and the LMA may or may not be aligned at the same\nboundary, leading to rewrite_elf_program_header() returning false even\nfor valid ELF files that do not contain any segments whose first section\ndoes not start at the beginning of the segment.\n\nThis patch adds an alternate check directly comparing the segment and\nsection LMAs for the segments that do not contain any headers; in case a\nsegment contains a file or program header, the function may still\nerroneously return false.\n\nA more fundamental fix should re-implement the function such that it\nuses VMA for verifying that the first section in a segment starts at the\nbeginning of the segment.\n\nSigned-off-by: Stephanos Ioannidis ","shortMessageHtmlLink":"elf: Workaround for segment first section address check in phdr rewrite"}},{"before":"db8bd068edeaac983273727d9322fc1867702d15","after":"66646cfeb0769c1eb5c98cb40939a443f73ccfcd","ref":"refs/heads/zephyr-gdb-12.1","pushedAt":"2023-12-07T01:53:10.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"stephanosio","name":"Stephanos Ioannidis","path":"/stephanosio","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11345418?s=80&v=4"},"commit":{"message":"microblaze: apply gdb patches from meta-xilinx repository\n\nThis patchset fixes many known issues on gnu-toolchain for microblaze.\nBut mainly the atomic-cas and binutils incorrect relocation issues. For gdb\nthis patchset resolves the segfault caused by inline-sniffer.\n\nPatches obtained from https://github.com/xilinx/meta-xilinx/ repository,\nfrom meta-microblaze/recipes-devtools/gdb/gdb path.\nI've filtered out microblaze64 and microblaze-linux patches because they\ncause microblaze-gdb to segfault at startup and more importantly,\nunnecessary for Zephyr. Below is a list of patches applied and squashed:\n\n0008-Patch-MicroBlaze.patch\n\nSigned-off-by: Alp Sayin ","shortMessageHtmlLink":"microblaze: apply gdb patches from meta-xilinx repository"}},{"before":"f36cd8b8f9c556a24f8df9097eb52da237c01982","after":null,"ref":"refs/heads/fix_mve_vcvtne","pushedAt":"2023-04-23T04:47:56.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"stephanosio","name":"Stephanos Ioannidis","path":"/stephanosio","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11345418?s=80&v=4"}},{"before":"1cdd11427dad28d698edfa41df3e370e58d857d9","after":"f36cd8b8f9c556a24f8df9097eb52da237c01982","ref":"refs/heads/zephyr-binutils-2_38","pushedAt":"2023-04-23T04:47:47.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"stephanosio","name":"Stephanos Ioannidis","path":"/stephanosio","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11345418?s=80&v=4"},"commit":{"message":"gas: arm: Fix a further IT-predicated vcvt issue in the presense of MVE vcvtn\n\nPreviously we had experienced issues with assembling a \"VCVTNE\" instruction\nin the presence of the MVE architecture extension, because it could be\ninterpreted both as:\n\n* The base instruction VCVT + NE for IT predication when inside an IT block.\n* The MVE instruction VCVTN + E in the Else of a VPT block.\n\nGiven a C reproducer of:\n```\nint test_function(float value)\n{\n int ret_val = 10;\n if (value != 0.0)\n {\n ret_val = (int) value;\n }\n return ret_val;\n}\n```\nGCC generates a VCVTNE instruction based on the `truncsisf2_vfp`\npattern, which will look like:\n`vcvtne.s32.f32 s-reg, s-reg`\nThis still triggers an error due to being misidentified as \"vcvtn+e\"\nSimilar errors were found with other type combinations and instruction\npatterns (these have all been added to the testing of this patch).\n\nThis class of errors was previously worked around by:\nhttps://sourceware.org/pipermail/binutils/2020-August/112728.html\nwhich addressed this by looking at the operand types, however,\nthat isn't adequate to cover all the extra cases that have been\nfound. Instead, we add some special-casing logic earlier when\nthe instructions are parsed that is conditional on whether we are\nin a VPT block or not, when the instruction is parsed.\n\ngas/ChangeLog:\n\n\t* config/tc-arm.c (opcode_lookup): Add special vcvtn handling.\n\t* testsuite/gas/arm/mve-vcvtne-it-bad.l: Add further testing.\n\t* testsuite/gas/arm/mve-vcvtne-it-bad.s: Likewise.\n\t* testsuite/gas/arm/mve-vcvtne-it.d: Likewise.\n\t* testsuite/gas/arm/mve-vcvtne-it.s: Likewise.\n\n(cherry picked from commit 656412a7a4da0aef43ead1ea976ba0235a7ec30a)\nSigned-off-by: Stephanos Ioannidis ","shortMessageHtmlLink":"gas: arm: Fix a further IT-predicated vcvt issue in the presense of M…"}},{"before":"60ad592be1a339590bd1cfeea1cbd3c892e28b53","after":"f36cd8b8f9c556a24f8df9097eb52da237c01982","ref":"refs/heads/fix_mve_vcvtne","pushedAt":"2023-04-22T13:21:20.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"stephanosio","name":"Stephanos Ioannidis","path":"/stephanosio","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11345418?s=80&v=4"},"commit":{"message":"gas: arm: Fix a further IT-predicated vcvt issue in the presense of MVE vcvtn\n\nPreviously we had experienced issues with assembling a \"VCVTNE\" instruction\nin the presence of the MVE architecture extension, because it could be\ninterpreted both as:\n\n* The base instruction VCVT + NE for IT predication when inside an IT block.\n* The MVE instruction VCVTN + E in the Else of a VPT block.\n\nGiven a C reproducer of:\n```\nint test_function(float value)\n{\n int ret_val = 10;\n if (value != 0.0)\n {\n ret_val = (int) value;\n }\n return ret_val;\n}\n```\nGCC generates a VCVTNE instruction based on the `truncsisf2_vfp`\npattern, which will look like:\n`vcvtne.s32.f32 s-reg, s-reg`\nThis still triggers an error due to being misidentified as \"vcvtn+e\"\nSimilar errors were found with other type combinations and instruction\npatterns (these have all been added to the testing of this patch).\n\nThis class of errors was previously worked around by:\nhttps://sourceware.org/pipermail/binutils/2020-August/112728.html\nwhich addressed this by looking at the operand types, however,\nthat isn't adequate to cover all the extra cases that have been\nfound. Instead, we add some special-casing logic earlier when\nthe instructions are parsed that is conditional on whether we are\nin a VPT block or not, when the instruction is parsed.\n\ngas/ChangeLog:\n\n\t* config/tc-arm.c (opcode_lookup): Add special vcvtn handling.\n\t* testsuite/gas/arm/mve-vcvtne-it-bad.l: Add further testing.\n\t* testsuite/gas/arm/mve-vcvtne-it-bad.s: Likewise.\n\t* testsuite/gas/arm/mve-vcvtne-it.d: Likewise.\n\t* testsuite/gas/arm/mve-vcvtne-it.s: Likewise.\n\n(cherry picked from commit 656412a7a4da0aef43ead1ea976ba0235a7ec30a)\nSigned-off-by: Stephanos Ioannidis ","shortMessageHtmlLink":"gas: arm: Fix a further IT-predicated vcvt issue in the presense of M…"}},{"before":null,"after":"60ad592be1a339590bd1cfeea1cbd3c892e28b53","ref":"refs/heads/fix_mve_vcvtne","pushedAt":"2023-04-22T13:19:57.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"stephanosio","name":"Stephanos Ioannidis","path":"/stephanosio","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11345418?s=80&v=4"},"commit":{"message":"gas: arm: Fix a further IT-predicated vcvt issue in the presense of MVE vcvtn\n\nPreviously we had experienced issues with assembling a \"VCVTNE\" instruction\nin the presence of the MVE architecture extension, because it could be\ninterpreted both as:\n\n* The base instruction VCVT + NE for IT predication when inside an IT block.\n* The MVE instruction VCVTN + E in the Else of a VPT block.\n\nGiven a C reproducer of:\n```\nint test_function(float value)\n{\n int ret_val = 10;\n if (value != 0.0)\n {\n ret_val = (int) value;\n }\n return ret_val;\n}\n```\nGCC generates a VCVTNE instruction based on the `truncsisf2_vfp`\npattern, which will look like:\n`vcvtne.s32.f32 s-reg, s-reg`\nThis still triggers an error due to being misidentified as \"vcvtn+e\"\nSimilar errors were found with other type combinations and instruction\npatterns (these have all been added to the testing of this patch).\n\nThis class of errors was previously worked around by:\nhttps://sourceware.org/pipermail/binutils/2020-August/112728.html\nwhich addressed this by looking at the operand types, however,\nthat isn't adequate to cover all the extra cases that have been\nfound. Instead, we add some special-casing logic earlier when\nthe instructions are parsed that is conditional on whether we are\nin a VPT block or not, when the instruction is parsed.\n\ngas/ChangeLog:\n\n\t* config/tc-arm.c (opcode_lookup): Add special vcvtn handling.\n\t* testsuite/gas/arm/mve-vcvtne-it-bad.l: Add further testing.\n\t* testsuite/gas/arm/mve-vcvtne-it-bad.s: Likewise.\n\t* testsuite/gas/arm/mve-vcvtne-it.d: Likewise.\n\t* testsuite/gas/arm/mve-vcvtne-it.s: Likewise.\n\nSigned-off-by: Stephanos Ioannidis ","shortMessageHtmlLink":"gas: arm: Fix a further IT-predicated vcvt issue in the presense of M…"}},{"before":"6a1be1a6a571957fea8b130e4ca2dcc65e753469","after":"1cdd11427dad28d698edfa41df3e370e58d857d9","ref":"refs/heads/zephyr-binutils-2_38","pushedAt":"2023-03-08T16:57:49.861Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"stephanosio","name":"Stephanos Ioannidis","path":"/stephanosio","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11345418?s=80&v=4"},"commit":{"message":"microblaze: Invalid data offsets (pointer) after relaxation.\nProposed patch from community member (dednev@rambler.ru) against 2021.1\n[CR-1115232]\n\nSigned-off-by: Mark Hatle \n\nPatch file taken and partially applied from:\nhttps://github.com/Xilinx/meta-xilinx/blob/master/meta-microblaze/recipes-devtools/binutils/binutils/0038-Invalid-data-offsets-pointer-after-relaxation.-Propo.patch\nSigned-off-by: Alp Sayin ","shortMessageHtmlLink":"microblaze: Invalid data offsets (pointer) after relaxation."}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOS0xOFQxNToyNjoxMy4wMDAwMDBazwAAAAS53VcK","startCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOS0xOFQxNToyNjoxMy4wMDAwMDBazwAAAAS53VcK","endCursor":"Y3Vyc29yOnYyOpK7MjAyMy0wMy0wOFQxNjo1Nzo0OS44NjE2OTJazwAAAAL_Me3e"}},"title":"Activity · zephyrproject-rtos/binutils-gdb"}