{"push_id":2861472538,"size":11,"distinct_size":11,"ref":"refs/heads/upstream/master","head":"1aac008f1c2f0a239b7ba26efe9d6b68044cddf8","before":"d1908f2d6b9f161b6a31449e83e1b671acb99620","commits":[{"sha":"2a62dfa93f1980fd8d5b0651753c550942fa30b6","author":{"name":"Joel Brobecker","email":"c7e71725c97f9c37b4edbe71d193d6b3659aa171@adacore.com"},"message":"(Ada) assigning packed array aggregate with variable as component\n\nConsider a variable \"PRA\" defined as a packed array of packed\nrecords as follow:\n\n   subtype Int is Integer range 0 .. 7;\n   type Packed_Rec is record\n      X, Y : Int;\n      W    : Integer;\n   end record;\n   pragma Pack (Packed_Rec);\n   type Packed_RecArr is array (Integer range <>) of Packed_Rec;\n   pragma Pack (Packed_RecArr);\n\n   PRA : Packed_RecArr (1 .. 3);\n\nConsider also a variable \"PR\", which is a Packed_Rec record,\ndeclared as follow:\n\n   PR : Packed_Rec := (2, 2, 2);\n\nTrying to assign a new value to PRA using an aggregate expression\nwhere one of the components is our variable PR yields the wrong\nresult on big-endian machines (e.g. on ppc-linux):\n\n    (gdb) p pra := (pr, (2,2,2), (2,2,2))\n    $6 = ((x => 1, y => 0, w => 8), [...]\n\nOn the other hand, replacing \"pr\" by \"(2,2,2)\" does work.\n\nI tracked the issue down to the bit offset we use to extract\nthe value of \"PR\" and copy it inside PRA. in value_assign_to_component,\nwe have:\n\n  if (gdbarch_bits_big_endian (get_type_arch (value_type (container))))\n    move_bits ([target buffer], [bit offset in target buffer],\n               [source buffer where PR is stored],\n               TYPE_LENGTH (value_type (component)) * TARGET_CHAR_BIT - bits,\n               bits, 1);\n\nThe issue is with the third-to-last argument, which provides the bit\noffset where the value of PR is stored relative to its start address,\nand therefore the bit offset relative to the start of the source\nbuffer passed as the previous argument.\n\nIn our case, component is a 38bit packed record whose TYPE_LENGTH\nis 5 bytes, so the bit-offset that gets calculated is 2 (bits).\nHowever, that formula only really applies to scalars, whereas\nin our case, we have a record (struct). The offset in the non-scalar\ncase should be zero.\n\ngdb/ChangeLog:\n\n        * ada-lang.c (value_assign_to_component): In the case of\n        big-endian targets, extract the bits of the given VAL\n        using an src_offset of zero if container is not a scalar.\n\ngdb/testsuite/ChangeLog:\n\n        * gdb.ada/packed_array_assign: New testcase.","distinct":true,"url":"https://api.github.com/repos/fuchsia-mirror/third_party-binutils-gdb/commits/2a62dfa93f1980fd8d5b0651753c550942fa30b6"},{"sha":"fb44b1a737ee7d53d5d88c4f2a3d449e8084d6c2","author":{"name":"Joel Brobecker","email":"c7e71725c97f9c37b4edbe71d193d6b3659aa171@adacore.com"},"message":"(Ada) infinite loop when hitting unhandled exception catchpoint\n\nWhen debugging a program compiled with an older version of GNAT,\nhitting a catchpoint on unhandled exceptions can caused GDB to\ngot into an infinite loop. This happens while trying to find\nthe name of the exception that was raised. For that, it searches\nfor a frame corresponding to a specific function we know gets\ncalled during the exeption handling.\n\nIn our particular case, the compiler was too old, and so GDB never\nfound that frame, and eventually got past the \"main\" subprogram,\nall the way to system frames, where no symbol was available.\nAs a result, the code addresses could not be resolved into\na function name, leading to the infinite loop because of\na misplaced update of our loop variable \"fi\":\n\n    while (fi != NULL)\n      {\n        char *func_name;\n        enum language func_lang;\n\n        find_frame_funname (fi, &func_name, &func_lang, NULL);\n        if (func_name != NULL)\n          {\n            make_cleanup (xfree, func_name);\n\n            if (strcmp (func_name,\n                        data->exception_info->catch_exception_sym) == 0)\n              break; /* We found the frame we were looking for...  */\n            fi = get_prev_frame (fi);\n          }\n      }\n\nIf FUNC_NAME is NULL, then FI never gets updated ever after!\n\ngdb/ChangeLog:\n\n        * ada-lang.c (ada_unhandled_exception_name_addr_from_raise):\n        Move update of loop variable \"fi\".\n\nNo testcase added, as the existing testcase gdb.ada/catch_ex.exp\nshould trigger it when using an older version of GNAT as the Ada\ncompiler.","distinct":true,"url":"https://api.github.com/repos/fuchsia-mirror/third_party-binutils-gdb/commits/fb44b1a737ee7d53d5d88c4f2a3d449e8084d6c2"},{"sha":"57aff202b4b17a05d73e71680a26fe12a817f110","author":{"name":"Joel Brobecker","email":"c7e71725c97f9c37b4edbe71d193d6b3659aa171@adacore.com"},"message":"(Ada) \"catch assert\" spurious internal error\n\nWe noticed while debugging a program compiled without assertions\nenabled and using an older compiler that inserting a catchpoint\non failed assertions would cause an internal error:\n\n    (gdb) catch assert\n    ../../src/gdb/ada-lang.c:13321: internal-error: ada_exception_sal:\n    Assertion`sym != NULL' failed.\n    A problem internal to GDB has been detected,\n\nThis is due to a combination of factors:\n\n  1. With older versions of the compiler, the function used as a hook\n     was provided by a unit that's different from the unit which\n     provides the hooks for the other exception catchpoints.\n\n  2. The program either does not use any assertion, or is compiled\n     without the assertions enabled.\n\nWith newer versions of the compiler, all such functions are provided\nby the same unit, so should normally always be available.  However,\nthere can still be reasons why this is not the case. Consider, for\ninstance, the case of a runtime compiled with -ffunction-sections,\nin which case the hook might be eliminated unless assertions are\nused and enabled.\n\nSo this patch transforms the internal error into a simple error.\n\ngdb/ChangeLog:\n\n        * ada-lang.c (ada_exception_sal): Replace gdb_assert calls\n        by calls to error.\n\nNo testcase added, as the existing testcase gdb.ada/catch_ex.exp\nshould trigger it when using an older version of GNAT as the Ada\ncompiler.","distinct":true,"url":"https://api.github.com/repos/fuchsia-mirror/third_party-binutils-gdb/commits/57aff202b4b17a05d73e71680a26fe12a817f110"},{"sha":"0d81f350ec01630ef7cd9ae4385a1dc504c54d73","author":{"name":"Jerome Guitton","email":"83c6c717b81de6af9945371cb7d361cdf9403609@adacore.com"},"message":"Handle PPC64 function descriptor in Ada decoding\n\nOn PPC64, the entry point of the function \"FN\" is \".FN\" when a function\ndescriptor is used. One of the consequences of this is that GDB then\npresents the name of the function to the user (eg: in backtraces) with\nthe leading dot, which is a low-level internal detail that the user\nshould not be seeing.  The Ada decoding should strip it.\n\ngdb/ChangeLog:\n\n\t* ada-lang.c (ada_decode): strip dot prefix in symbol name.\n\nNo testcase added, as a number of existing testcases should already\ndemonstrate that problem.","distinct":true,"url":"https://api.github.com/repos/fuchsia-mirror/third_party-binutils-gdb/commits/0d81f350ec01630ef7cd9ae4385a1dc504c54d73"},{"sha":"d8ce91275e421dfe57aa4e79bb9a58824c155e96","author":{"name":"Joel Brobecker","email":"c7e71725c97f9c37b4edbe71d193d6b3659aa171@adacore.com"},"message":"minor reformatting in ada-lang.c::ada_to_fixed_value\n\nThe arguments in the call to ada_to_fixed_value_create where\nimproperly aligned. But I also noticed that all the arguments\ndo fit on a single-line (up to 79 characters). So this patch\njust fixes the code by putting everything on that same line.\n\ngdb/ChangeLog:\n\n        * ada-lang.c (ada_to_fixed_value): Minor reformatting in\n        call to ada_to_fixed_value_create.","distinct":true,"url":"https://api.github.com/repos/fuchsia-mirror/third_party-binutils-gdb/commits/d8ce91275e421dfe57aa4e79bb9a58824c155e96"},{"sha":"16b9eb7bfa56f060d183aa44165bf75cb3c414d8","author":{"name":"Joel Brobecker","email":"c7e71725c97f9c37b4edbe71d193d6b3659aa171@adacore.com"},"message":"(Ada) slightly incorrect bounds for type of array indexed by enum\n\nConsider the following code:\n\n   type Enumerated is (Enum_A, Enum_B, Enum_C, Enum_Last);\n   type Table is array (Enumerated) of Integer;\n   --  Declare a variable of type Table to make sure the compiler\n   --  does emit the debugging information for that type.\n   V : Table := (others => 1);\n\nTrying to print the type description of type Table, or of variable V\nyields:\n\n    (gdb) ptype v\n    type = array (0 .. 3) of integer\n    (gdb) ptype example.table\n    type = array (0 .. 3) of integer\n\nThe compiler generates an XA type for the bounds...\n\n <1><cf6>: Abbrev Number: 13 (DW_TAG_structure_type)\n    <cf7>   DW_AT_name        : example__table___XA\n\n... whose member is described as being as:\n\n <2><cfe>: Abbrev Number: 14 (DW_TAG_member)\n    <cff>   DW_AT_name        : example__enumerated\n    <d05>   DW_AT_type        : <0xc69>\n\nThis leads us to DIE 0xc69, which is our enumeration type:\n\n <2><c69>: Abbrev Number: 4 (DW_TAG_enumeration_type)\n    <c6a>   DW_AT_name        : example__enumerated\n\nNormally, for arrays, we expect a range type, rather than an enumerated\ntype. However, for a situation like this, where the range of the array\nindex is the full enumeration type, it seems like a waste to require\nan extra range layer.\n\nInstead, looking at print_range, we see that we print the bounds\nof our range using the target type:\n\n       target_type = TYPE_TARGET_TYPE (type);\n       if (target_type == NULL)\n         target_type = type;\n       [...]\n       ada_print_scalar (target_type, lo, stream);\n       fprintf_filtered (stream, \" .. \");\n       ada_print_scalar (target_type, hi, stream);\n\nIn this case, this causes us to use the enumerated type's subtype,\nwhich is a plain integer type, hence the output we get. However,\nthere is no reason for using the target type, even in the TYPE_CODE_RANGE\nsituation. So this patch fixes the issue by simply printing the bounds\nusing the type being given, instead of its target type.\n\ngdb/ChangeLog:\n\n        * ada-typeprint.c (print_range): Print the bounds using TYPE\n        rather than its TYPE_TARGET_TYPE.\n\nA new test for this isn't necessary, as existing tests will demonstrate\nthis issue once a change in the compiler triggering the generation of\nthis type of debugging info gets pushed.","distinct":true,"url":"https://api.github.com/repos/fuchsia-mirror/third_party-binutils-gdb/commits/16b9eb7bfa56f060d183aa44165bf75cb3c414d8"},{"sha":"95f39a5b2755e5aaaceb6248e585f8a593542331","author":{"name":"Joel Brobecker","email":"c7e71725c97f9c37b4edbe71d193d6b3659aa171@adacore.com"},"message":"ada-lang.c::ada_value_cast: remove unnecessary parentheses\n\nNo other code change.\n\ngdb/ChangeLog:\n\n        * ada-lang.c (ada_value_cast): Remove unnecessary parentheses.","distinct":true,"url":"https://api.github.com/repos/fuchsia-mirror/third_party-binutils-gdb/commits/95f39a5b2755e5aaaceb6248e585f8a593542331"},{"sha":"424da6cf3b30b889ff577b1babd09777148dc0e0","author":{"name":"Joel Brobecker","email":"c7e71725c97f9c37b4edbe71d193d6b3659aa171@adacore.com"},"message":"(Ada) fix handling of expression with parameterless function call\n\nConsider the following function, which takes no parameter and returns\nan integer:\n\n    function Something return Integer;\n\nFor the purpose of this discussion, our function has been implemented\nto always return 124:\n\n    function Something return Integer is\n    begin\n       return 124;\n    end Something;\n\nIn Ada, such function can been called without using the parentheses.\nFor instance, in the statement below, variable My_Value is assigned\nthe returned value from the call to Something:\n\n    My_Value := Something;\n\nThe Ada expression interpeter in GDB supports this case, as we can\nsee below:\n\n    (gdb) print something\n    $1 = 124\n\nHowever, we get fairly strange results when trying to use this feature\nas part of a larger expression. For instance:\n\n    (gdb) print something + 1\n    $2 = 248\n\nThe problem occurs while doing the resolution pass of the expression.\nAfter prefixying the expression, we obtain the following expression:\n\n    0  BINOP_ADD\n    1    OP_VAR_VALUE          Block @0x2021550, symbol @0x20213a0 (pck.something)\n    5    OP_LONG               Type @0x1e3c170 (int), value 1 (0x1)\n\nThe resolution pass is then expected to remove the OP_VAR_VALUE\nentry, and replace it with an OP_FUNCALL. This is what the call\nto replace_operator_with_call in ada-lang.c::resolve_subexp is\nexpected to do:\n\n      if (deprocedure_p\n          && (TYPE_CODE (SYMBOL_TYPE (exp->elts[pc + 2].symbol))\n              == TYPE_CODE_FUNC))\n        {\n          replace_operator_with_call (expp, pc, 0, 0,\n                                      exp->elts[pc + 2].symbol,\n                                      exp->elts[pc + 1].block);\n          exp = expp->get ();\n        }\n\nThe problem is that we're passing OPLEN (zero -- 4th parameter in\nthe call), and so replace_operator_with_call ends up removing zero\nelement from our expression, and inserting the corresponding OP_FUNCALL\ninstead. As a result, instead of having the OP_LONG (1) as the second\nargument of the BINOP_ADD, it is now the OP_VAR_VALUE that we were\nmeant to replace. That OP_VAR_VALUE then itself gets transformed into\nan OP_FUNCALL, with the same issue, and eventually, the resolved\nexpression now looks like this:\n\n     0  BINOP_ADD\n     1    OP_FUNCALL            Number of args: 0\n     4      OP_VAR_VALUE          Block @0x2021550, symbol @0x20213a0 (pck.something)\n     8    OP_FUNCALL            Number of args: 0\n    11      OP_VAR_VALUE          Block @0x2021550, symbol @0x20213a0 (pck.something)\n    15  OP_VAR_VALUE          Block @0x2021550, symbol @0x20213a0 (pck.something)\n    19  OP_LONG               Type @0x1e3c170 (int), value 1 (0x1)\n\nThis explains why we get twice the result of the function call\ninstead of its value plus one. The extra entries in the expression\nat the end are just ignored.\n\nThis patch fixes the issue by calling replace_operator_with_call\nwith the correct OPLEN equal to the size of an OP_VAR_VALUE (4).\n\ngdb/ChangeLog:\n\n        * ada-lang.c (resolve_subexp): Pass correct OPLEN in call to\n        replace_operator_with_call.\n\ngdb/testsuite/ChangeLog:\n\n        * gdb.ada/expr_with_funcall: New testcase.","distinct":true,"url":"https://api.github.com/repos/fuchsia-mirror/third_party-binutils-gdb/commits/424da6cf3b30b889ff577b1babd09777148dc0e0"},{"sha":"0653638f9f0efdb1561db8e2faff2580e09658af","author":{"name":"GDB Administrator","email":"46ff6e41b02a6ff6bd50cc64faab96b75208d63d@sourceware.org"},"message":"Automatic date update in version.in","distinct":true,"url":"https://api.github.com/repos/fuchsia-mirror/third_party-binutils-gdb/commits/0653638f9f0efdb1561db8e2faff2580e09658af"},{"sha":"332cf4c9251a31f0addc2ce2970c9a8bb0c16f96","author":{"name":"Tom Tromey","email":"96835dd8bfa718bd6447ccc87af89ae1675daeca@tromey.com"},"message":"Allow a pretty-printer without a to_string method\n\nPR python/16047 points out that, while the documentation says that the\nto_string method is optional for a pretty-printer, the code disagrees\nand throws an exception.  This patch fixes the problem.  varobj is\nalready ok here.\n\nTested on x86-64 Fedora 26.\n\ngdb/ChangeLog\n2018-09-08  Tom Tromey  <tom@tromey.com>\n\n\tPR python/16047:\n\t* python/py-prettyprint.c (pretty_print_one_value): Check for\n\tto_string method.\n\ngdb/testsuite/ChangeLog\n2018-09-08  Tom Tromey  <tom@tromey.com>\n\n\tPR python/16047:\n\t* gdb.python/py-prettyprint.py (pp_int_typedef3): New class.\n\t(register_pretty_printers): Register new printer.\n\t* gdb.python/py-prettyprint.exp (run_lang_tests): Add int_type3\n\ttest.\n\t* gdb.python/py-prettyprint.c (int_type3): New typedef.\n\t(an_int_type3): New global.","distinct":true,"url":"https://api.github.com/repos/fuchsia-mirror/third_party-binutils-gdb/commits/332cf4c9251a31f0addc2ce2970c9a8bb0c16f96"},{"sha":"1aac008f1c2f0a239b7ba26efe9d6b68044cddf8","author":{"name":"Tom Tromey","email":"96835dd8bfa718bd6447ccc87af89ae1675daeca@tromey.com"},"message":"Make py-prettyprint.exp test names unique\n\nI noticed that the py-prettyprint.exp test names were not unique.\nThis patch fixes the problem via with_test_prefix.\n\ngdb/testsuite/ChangeLog\n2018-09-08  Tom Tromey  <tom@tromey.com>\n\n\t* gdb.python/py-prettyprint.exp: Use with_test_prefix.","distinct":true,"url":"https://api.github.com/repos/fuchsia-mirror/third_party-binutils-gdb/commits/1aac008f1c2f0a239b7ba26efe9d6b68044cddf8"}]}
{"actor":{"display_login":"fuchsia-infra-bot"}}